From frode@dxcern.cern.ch Wed Mar 01 04:07:18 1995 
Received: from dxmint.cern.ch (dxmint.cern.ch [128.141.1.113]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id EAA16148 for 
<hfsig@tapr.org>; Wed, 1 Mar 1995 04:07:13 -0600 
Received: from dxcern.cern.ch by dxmint.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA14971; Wed, 1 Mar 1995 11:05:33 +0100 
Received: by dxcern.cern.ch (5.65/DEC-Ultrix/4.3) 
id AA16487; Wed, 1 Mar 1995 11:05:31 +0100 
Date: Wed, 1 Mar 1995 11:05:29 +0100 (MET) 
From: Frode Weierud <frode@dxcern.cern.ch> 
To: HFSIG TAPR <hfsig@tapr.org> 
Subject: Reed-Solomon Package 
Message-Id: <Pine.ULT.3.91.950301110059 .3464A-100000@dxcern.cern.ch> 
Mime-Version: 1.0 
Content-Type: TEXT/PLAIN; charset=US-ASCII 


Hi all, 


I have just uploaded a package of routines for experimenting with 
Reed-Solomon error correcting codes on ftp.tapr.org, in the 
tapr/SIG/hfsig/upload directory. The archive is called RSpack.zip. 


Here is the content of the RSpack.txt file: 


RSpack is a complete package for experimenting with Reed-Solomon 
error correcting codes. The author of RSpack is: 


Jan-Mark Wams. 
email: jms@cs.vu.nl 
smail: Jan-Mark Wams 
Jephtastraat 67-5 
1055 JS Amsterdam 
voice: .. (31-20 / 020) 6 81 43 84 


Here is a short extract from the readme file: 


THE RS-PACKAGE 


Below is my RS-package. It should run on MS-DOS and UNIX provided 
a ANSI-C compiler is used (like gcc or turbo C). 


It has two main parts: 


i) A generator program. 
ii) A (en/de)-code program. 


The first program (‘‘rsgen.c'') is a C program that generates a 
include file for the second program (‘‘rsbody.c''). The 
(en/de)-coding is an example of how the generated file of the 
generator program could be used. The net effect of a version 

of the (en/de)-code-program is a filter, that allows one to 
protect data. For testing purposes, there is a program for 


altering files, and a program for deleting bytes from a file. 
These can be used to simulate a bad network. 


I have made some small changes to the original Makefile and a few of 
the source files as describes in the readme.1st file. I have also 
included a small tutorial on Reed-Solomon codes written by Colin Plumb. 


Contributed by Frode Weierud, F/LA2RL 
1 March 1995 


73 Frode 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKAKK 


* Frode Weierud Phone : 41 22 7674794 * 

* CERN, SL Fax : 41 22 7679185 * 

* CH-1211 Geneva 23 E-mail : frode@dxcern.cern.ch 
x 

* Switzerland x 


KKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKEKKKKKKKKKEKKKKKKKKKKKKKKKKKKKKKKKKKKKKKKAKKK 


From SJF@rpsl.co.uk Wed Mar 01 04:22:36 1995 
Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id EAA16348 for 
<hfsig@tapr.org>; Wed, 1 Mar 1995 04:22:31 -0600 
Received: from rpsl.demon.co.uk by post.demon.co.uk id aaQ8402; 
1 Mar 95 10:19 GMT 

Received: from mail.rpsl.co.uk by rpsl.demon.co.uk with SMTP 

id AA3523 ; Wed, 01 Mar 95 10:25:03 GMT 
Received: from RPSL/SpoolDir by mail.rpsl.co.uk (Mercury 1.13); 

Wed, 1 Mar 95 10:19:43 GMT 
Received: from SpoolDir by RPSL (Mercury 1.13); Wed, 1 Mar 95 10:18:34 GMT 
From: STUART FAWCETT <SJF@rpsl.co.uk> 
Organization: Racal Positioning Systems Limited 
To: hfsig@tapr.org 


Date: Wed, 1 Mar 1995 10:18:34 GMT 
Subject: 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.11a) 


Message-ID: <300F4F20E36@mail.rpsl.co.uk> 


Subscribe 
From kurpiers@zeus.uet.e-technik.th-darmstadt.de Wed Mar 01 12:03:36 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA18979 for 
<hfsig@tapr.org>; Wed, 1 Mar 1995 12:03:04 -0600 
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) 
by rs2.hrz.th-darmstadt.de with SMTP id AA16952 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Wed, 1 Mar 1995 19:00:47 +0100 
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de 
[130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id 
TAA19385 for <hfsig@tapr.org>; Wed, 1 Mar 1995 19:00:43 +0100 


From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 

Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad 
(8.6.4/8.6.4) id SAA17859 for hfsig@tapr.org; Wed, 1 Mar 1995 18:58:38 +0100 
Message-Id: <199503011758.SAA17859@hades.uet.e-technik.th-darmstad> 

Subject: Re: HF Channel Simulator 

To: hfsig@tapr.org 

Date: Wed, 1 Mar 1995 18:58:37 +0100 (MEZ) 

In-Reply-To: <34280A72BE9@frl.orst.edu> from "Johan Forrer" at Feb 28, 95 11:31:40 
am 

X-Mailer: ELM [version 2.4 PL24] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 2038 


> The procedure is as follows (this is performed in triplicate): 

> 

> 1). Create White Gaussian noise with a given standard deviation as 
> determined by the CCIR conditions that you are simulating. 

> 

> 2). Apply a complex low-pass filter to the points (complex) created 
> in (1). A Butterworth response is probably a good choice for 

> having low ripple in the pass band. A two-pole filter is quite 
> adequate. 

> 

> 

> 

> Johan, KC7WW 


The generated Gaussian noise is white in the frequency domain. From the CCIR 
report and from the Watterson paper it is clear, that the tap-gain function 
spectrum is the sum of two Gaussian functions of frequency. So I still 

think you have to use filters with Gaussian frequency response to convert 
the white noise to the spectrum we need. Furthermore, the CCIR report 

states that not only the tap-gain function has a Gaussian frequency 

spectrum with high probability but that a single-pole spectrum is not 

valid. So a two-pole filter can't be anything more but an approximation. 


The filters with Gaussian frequency response can easily be implemented as 
FIR filters (ok, Butterworth IIR filters would be easier... :-) ). 


As this is a rather important part of the simulator I think it is still 
important to talk about this filter... 


73' Alexander DL8AAU 


Alexander F. Kurpiers 

Technische Hochschule Darmstadt 
Institut fuer Uebertragungstechnik 
Merckstrasse 25 

D-64283 Darmstadt (Germany) 


Voice: +49-6151-162369 

Fax : +49-6151-165545 

EMail: kurpiers@zeus.uet.e-technik.th-darmstadt.de 
Hamradio: dl8aau@dbO0kg.#nds.deu.eu 


From mcdermot@aud.alcatel.com Wed Mar 01 14:13:57 1995 

Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with ESMTP id OAA20280 for <hfsig@tapr.org>; Wed, 1 Mar 1995 
14:13:50 -0600 

Received: by janus@1.aud.alcatel.com id <20629>; Wed, 1 Mar 1995 14:11:22 -0600 
Date: Wed, 1 Mar 1995 14:11:49 -0600 

From: mcdermot@aud.alcatel.com (Tom Mcdermott) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:297] Re: HF Channel Simulator 

Message-Id: <95Mar1.141122cst.20629@janus01.aud.alcatel.com> 


> The procedure is as follows (this is performed in triplicate): 

> 

> 1). Create White Gaussian noise with a given standard deviation as 
> determined by the CCIR conditions that you are simulating. 

> 

> 2). Apply a complex low-pass filter to the points (complex) created 
> in (1). A Butterworth response is probably a good choice for 

> having low ripple in the pass band. A two-pole filter is quite 
> adequate. 

> 

> 

> 

> Johan, KC7WW 


The generated Gaussian noise is white in the frequency domain. From the CCIR 
report and from the Watterson paper it is clear, that the tap-gain function 
spectrum is the sum of two Gaussian functions of frequency. So I still 

think you have to use filters with Gaussian frequency response to convert 
the white noise to the spectrum we need. Furthermore, the CCIR report 

states that not only the tap-gain function has a Gaussian frequency 

spectrum with high probability but that a single-pole spectrum is not 

valid. So a two-pole filter can't be anything more but an approximation. 


The filters with Gaussian frequency response can easily be implemented as 
FIR filters (ok, Butterworth IIR filters would be easier... :-) ). 


As this is a rather important part of the simulator I think it is still 
important to talk about this filter... 


73' Alexander DL8AAU 


VV VV VV VV V VV VV VV VV VV VV VV VV VV VV VOWV 


Alexander: I believe what the CCIR report requires is that the doppler 
frequency have a gaussian-distributed probability density function (PDF). 
This is not the same as the amplitude response of the filter. The gaussian 
PDF is generated by a gaussian random number generator. Since gaussian 
noise has a flat frequency response, a low pass filter obviously distorts 
the PDF. But a gaussian-amplitude LPF does not mean the the PDF of the 
output of the LPF is gaussian, because the LPF would have to be flat 
(ie no filter) to have gaussian PDF. Remember, gaussian PDF -> white noise 
(spectally flat, not shaped), and not-flat spectrum -> non-gaussian. 


So, the filter function does not alter the statistics of the distribution in 

a readily recognizable way. As the filter bandwidth changes, the 
standard-deviation of the distribution changes, since we are changing how 

the random numbers are being averaged -- this is equivalent to saying that the 
energy in the signal is changed, since RMS = Std. Dev. 


The math behind linear amplitude transformation of PDF's, and the resulting 
PDF is not readily available in the EE literature (well, I haven't 

seen it anyway). However, the math behind the summation of 
gaussian-distributed random numbers is well documented. In amplitude, 

the sum of multiple gaussian numbers with non-zero mean leads to a Rayleigh 
distribution (PDF) of the resultant amplitude. So this corresponds to the 
requirement that the path component have Rayleigh fading. 


How often the fade occurs is related to the doppler frequency. Soa 

wider low pass filter yields faster fading, equivalent to a larger 

std deviation of the doppler frequency. The sum of gaussian-distributed 
complex random numbers generates a random phase with a uniform distribution, 
and this matches the requirement that the phase of the path component be 
uniformly distributed. 


So, even without filtering, the doppler is gaussian-distributed. The purpose 
of the filter then is just to set the doppler rate, so we can control it 
for simulating different band conditions. 


- Tom, N5EG 


ps: I have no training in the area of stochastic processes, someone who 
has been there before can give us a discourse on what spectral filtering 
does to PDF's! It is a difficult job to mentally keep separate amplitude 
spectrum and PDF. 


From rick@itron-ca.com Wed Mar 01 16:58:53 1995 
Received: from itron-ca.com (gate.itron-ca.com [204.30.20.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id QAA21383 for 
<hfsig@tapr.org>; Wed, 1 Mar 1995 16:58:43 -0600 
Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id OAA16431; Wed, 1 
Mar 1995 14:56:52 -0800 
Received: from unknown(204.30.20.118) by gate.itron-ca.com via smap (V1.3mjr) 

id sma016429; Wed Mar 1 14:56:11 1995 
Date: Wed, 1 Mar 95 14:53:22 PST 
From: "Richard W. D. Booth" <rick@itron-ca.com> 


Subject: RE: [HFSIG:298] Re: HF Channel Simulator 

To: hfsig@tapr.org 

X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. 
Message-ID: <Chameleon.4.01.950301145609.rick@rick.itron-ca.com> 
MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


Tom, 

The output of a linear filter driven by a gaussian random process is still a 
gaussian 

random process...the spectrum (or autocorrelation function, if you will) is 
modified by the 

properties of the filter so the correlation between samples is modified. 
Rick 


w6nzk 

> 

>> > The procedure is as follows (this is performed in triplicate): 

>> > 

>> > 1). Create White Gaussian noise with a given standard deviation as 
>> > determined by the CCIR conditions that you are simulating. 

>> > 

>> > 2). Apply a complex low-pass filter to the points (complex) created 
>> > in (1). A Butterworth response is probably a good choice for 
>> > having low ripple in the pass band. A two-pole filter is quite 
>>> adequate. 

>> > 

>> > 

>> > 

>> > Johan, KC7WW 

>> 


>> The generated Gaussian noise is white in the frequency domain. From the CCIR 
>> report and from the Watterson paper it is clear, that the tap-gain function 
>> spectrum is the sum of two Gaussian functions of frequency. So I still 

>> think you have to use filters with Gaussian frequency response to convert 
>> the white noise to the spectrum we need. Furthermore, the CCIR report 

>> states that not only the tap-gain function has a Gaussian frequency 

>> spectrum with high probability but that a single-pole spectrum is not 

>> valid. So a two-pole filter can't be anything more but an approximation. 

>> 

>> The filters with Gaussian frequency response can easily be implemented as 
>> FIR filters (ok, Butterworth IIR filters would be easier... :-) ). 

>> 

>> As this is a rather important part of the simulator I think it is still 

>> important to talk about this filter... 


>> 73' Alexander DL8AAU 


> Alexander: I believe what the CCIR report requires is that the doppler 
>frequency have a gaussian-distributed probability density function (PDF). 
>This is not the same as the amplitude response of the filter. The gaussian 
>PDF is generated by a gaussian random number generator. Since gaussian 


>noise has a flat frequency response, a low pass filter obviously distorts 
>the PDF. But a gaussian-amplitude LPF does not mean the the PDF of the 
>output of the LPF is gaussian, because the LPF would have to be flat 

>(ie no filter) to have gaussian PDF. Remember, gaussian PDF -> white noise 
>(spectally flat, not shaped), and not-flat spectrum -> non-gaussian. 

> 

>So, the filter function does not alter the statistics of the distribution in 
>a readily recognizable way. As the filter bandwidth changes, the 
>standard-deviation of the distribution changes, since we are changing how 


>the random numbers are being averaged -- this is equivalent to saying that the 
>energy in the signal is changed, since RMS = Std. Dev. 
> 


>The math behind linear amplitude transformation of PDF's, and the resulting 
>PDF is not readily available in the EE literature (well, I haven't 

>seen it anyway). However, the math behind the summation of 
>gaussian-distributed random numbers is well documented. In amplitude, 

>the sum of multiple gaussian numbers with non-zero mean leads to a Rayleigh 
>distribution (PDF) of the resultant amplitude. So this corresponds to the 
>requirement that the path component have Rayleigh fading. 

> 

>How often the fade occurs is related to the doppler frequency. Soa 

>wider low pass filter yields faster fading, equivalent to a larger 

>std deviation of the doppler frequency. The sum of gaussian-distributed 
>complex random numbers generates a random phase with a uniform distribution, 
>and this matches the requirement that the phase of the path component be 
>uniformly distributed. 

> 

>So, even without filtering, the doppler is gaussian-distributed. The purpose 
>of the filter then is just to set the doppler rate, so we can control it 
>for simulating different band conditions. 

> 

> - Tom, N5EG 

> 

> 

>ps: I have no training in the area of stochastic processes, someone who 
>has been there before can give us a discourse on what spectral filtering 
>does to PDF's! It is a difficult job to mentally keep separate amplitude 
>spectrum and PDF. 

> 

> 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Thu Mar 02 02:28:09 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id CAA24942 for 
<hfsig@tapr.org>; Thu, 2 Mar 1995 02:27:44 -0600 
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) 
by rs2.hrz.th-darmstadt.de with SMTP id AA40088 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Thu, 2 Mar 1995 09:25:47 +0100 
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de 
[130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id 
JAA11794 for <hfsig@tapr.org>; Thu, 2 Mar 1995 09:25:40 +0100 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 


Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad 
(8.6.4/8.6.4) id JAAO09206 for hfsig@tapr.org; Thu, 2 Mar 1995 09:23:34 +0100 
Message-Id: <199503020823 . JAAO9206@hades.uet.e-technik.th-darmstad> 

Subject: Re: HF Channel Simulator 

To: hfsig@tapr.org 

Date: Thu, 2 Mar 1995 09:23:34 +0100 (MEZ) 

In-Reply-To: <Chameleon.4.01.950301145609.rick@rick.itron-ca.com> from "Richard W. 
D. Booth" at Mar 1, 95 05:08:15 pm 

X-Mailer: ELM [version 2.4 PL24] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 4956 


> 

> Tom, 

> The output of a linear filter driven by a gaussian random process is still a 
gaussian 

> random process...the spectrum (or autocorrelation function, if you will) is 
modified by the 

> properties of the filter so the correlation between samples is modified. 

> Rick 

> w6nzk 

>> 

Thank you, that's what I wanted to reply when your mail arrived here... 


> 

> Alexander: I believe what the CCIR report requires is that the doppler 
>frequency have a gaussian-distributed probability density function (PDF). 
>This is not the same as the amplitude response of the filter. The gaussian 
>PDF is generated by a gaussian random number generator. Since gaussian 
>noise has a flat frequency response, a low pass filter obviously distorts 
>the PDF. But a gaussian-amplitude LPF does not mean the the PDF of the 
>output of the LPF is gaussian, because the LPF would have to be flat 

>(ie no filter) to have gaussian PDF. Remember, gaussian PDF -> white noise 
>(spectally flat, not shaped), and not-flat spectrum -> non-gaussian. 


VVVV VV VV VV 


I know that a Gaussian distributed random variable (so the PDF is 
gaussian-distributed) has nothing to do with the power spectral densitiy. 
In our case it seems to be clear: 

(Watterson, Experimental Confirmation of an HF Channel Model): 


Statistical specifications for the tap-gain function involved 
three hypotheses: 1.) that each tap-gain function is a complex-Gaussian 
process that produces Rayleigh fading 
2.) that the tap-gain functions are independent 
3.) that each tap-gain function has a spectrum that 
in general is a sum of two Gaussian functions of 
FREQENCY, one for each magnetoionic component. 


1. is related to the pdf and without 2. we would have trouble implementing 
the model. But 3. says clearly, what the psd of the tap-gain functions 
have to look like. 


VV VV WV 


I 


>So, the filter function does not alter the statistics of the distribution in 
>a readily recognizable way. As the filter bandwidth changes, the 
>standard-deviation of the distribution changes, since we are changing how 

>the random numbers are being averaged -- this is equivalent to saying that the 
>energy in the signal is changed, since RMS = Std. Dev. 


was trying to calculate the RMS and found an equation by numeric 


integration. You will have to calculate it, otherwise you have to 
estimate the mean signal power at the point, where Gaussian noise is 
added to the fading signals (at the output of the HF simulator). 


VV VV VV MV 


>The math behind linear amplitude transformation of PDF's, and the resulting 
>PDF is not readily available in the EE literature (well, I haven't 

>seen it anyway). However, the math behind the summation of 
>gaussian-distributed random numbers is well documented. In amplitude, 

>the sum of multiple gaussian numbers with non-zero mean leads to a Rayleigh 
>distribution (PDF) of the resultant amplitude. So this corresponds to the 
>requirement that the path component have Rayleigh fading. 


As stated above, linear filtered of Gaussian distributed random variables 
will still be Gaussian distributed. You can think of the filtering 

process as a convolution with the impulse response of the filter. If 

you do this convolution with samples of the random variable (discrete time 
filtering), it's nothing more than multiplying the samples with constants 
and summing the result. As you said, the sum of any number of Gaussian 
distributed numbers is Gaussian ... :-) 

If you do the filtering continously, the summing will be an integration. 


About literature, try Papoulis, "Probability, Random Variables and 
Stochastic Processes". The book I'm using here is in German, so it is 
probably of no use for you. 


VV VV VV 


>How often the fade occurs is related to the doppler frequency. Soa 

>wider low pass filter yields faster fading, equivalent to a larger 

>std deviation of the doppler frequency. The sum of gaussian-distributed 
>complex random numbers generates a random phase with a uniform distribution, 
>and this matches the requirement that the phase of the path component be 
>uniformly distributed. 


Not only the sum of Gaussian-distributed complex numbers has a random 
phase... 

The phase of any Gaussian-distributed complex number with zero mean 
Gaussian distributed real and imaginary parts is uniform distributed and 
the amplitude is Rayleigh distributed. 


VV VV VV MV 


> 
>So, even without filtering, the doppler is gaussian-distributed. The purpose 
>of the filter then is just to set the doppler rate, so we can control it 

>for simulating different band conditions. 

> 

> - Tom, N5EG 

> 


>> 
> >ps: I have no training in the area of stochastic processes, someone who 

> >has been there before can give us a discourse on what spectral filtering 
> >does to PDF's! It is a difficult job to mentally keep separate amplitude 
> >spectrum and PDF. 

>> 


73' Alexander DL8AAU 


From mcdermot@aud.alcatel.com Thu Mar 02 07:50:09 1995 

Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with ESMTP id HAA25711 for <hfsig@tapr.org>; Thu, 2 Mar 1995 
07:50:06 -0600 

Received: by janus@1.aud.alcatel.com id <20648>; Thu, 2 Mar 1995 07:47:33 -0600 
Date: Thu, 2 Mar 1995 07:47:58 -0600 

From: mcdermot@aud.alcatel.com (Tom Mcdermott) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:299] Re: HF Channel Simulator 

Message-Id: <95Mar2.074733cst.20648@janus01.aud.alcatel.com> 


> Tom, 

> The output of a linear filter driven by a gaussian random process is still a 
gaussian 

> random process...the spectrum (or autocorrelation function, if you will) is 
modified by the 

> properties of the filter so the correlation between samples is modified. 

> Rick 

> w6nzk 


Rick: I agree. The power spectral density is, I think, the Fourier 
transform of the autocorrelation function, which for zero-mean gaussian 
process results in gaussian PSD. Since the gaussian PSD rolls-off pretty 
fast in amplitude vs. frequency already, the filter shape doesn't mess up 
the PSD too much, as long as it is reasonably square-ish (ie several poles). 
Sure, the shape is changed, but the error is fairly small, and is ignored 
for a multi-pole filter. 


So, filtering the white-noise signal results in another (almost) white 
noise signal of lower bandwidth, but is still has pretty much the same PSD 
shape except with a lower std. deviation. (PSD is equivalent to a PDF, 

I believe). 


- Tom, N5EG 

From kurpiers@zeus.uet.e-technik.th-darmstadt.de Thu Mar 02 09:10:59 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id JAA26406 for 
<hfsig@tapr.org>; Thu, 2 Mar 1995 09:04:52 -0600 
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) 
by rs2.hrz.th-darmstadt.de with SMTP id AA31934 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Thu, 2 Mar 1995 15:58:52 +0100 
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de 


[130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id 
PAA11903 for <hfsig@tapr.org>; Thu, 2 Mar 1995 15:58:52 +0100 

From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 

Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad 
(8.6.4/8.6.4) id PAA20626 for hfsig@tapr.org; Thu, 2 Mar 1995 15:56:45 +0100 
Message-Id: <199503021456.PAA20626@hades.uet.e-technik. th-darmstad> 

Subject: Re: HF Channel Simulator 

To: hfsig@tapr.org 

Date: Thu, 2 Mar 1995 15:56:44 +0100 (MEZ) 

In-Reply-To: <95Mar2.074733cst.20648@janus01.aud.alcatel.com> from "Tom Mcdermott" 
at Mar 2, 95 07:50:53 am 

X-Mailer: ELM [version 2.4 PL24] 

Mime-Version: 1.0 

Content-Type: text/plain; charset=US-ASCII 

Content-Transfer-Encoding: 7bit 

Content-Length: 1288 


Rick: I agree. The power spectral density is, I think, the Fourier 
transform of the autocorrelation function, which for zero-mean gaussian 
process results in gaussian PSD. Since the gaussian PSD rolls-off pretty 
fast in amplitude vs. frequency already, the filter shape doesn't mess up 
the PSD too much, as long as it is reasonably square-ish (ie several poles). 
Sure, the shape is changed, but the error is fairly small, and is ignored 
for a multi-pole filter. 


VV VV VV VV 


You can't tell the psd (power spectral density) from the 

pdf (probability density function), which is a measure for the 
amplitude distribution of a random variable. The psd is related to the 
autocorrelation function, it is indeed the Fourier transform of it. 


I.e. if the Gaussian distributed random variable is uncorrelated, the 
psd is a constant and thus the noise is called white. Filtering this 
white noise results in a new more or less correlated random variable 
whose pdf is still Gaussian distributed. 


> 

> So, filtering the white-noise signal results in another (almost) white 
> noise signal of lower bandwidth, but is still has pretty much the same PSD 
> shape except with a lower std. deviation. (PSD is equivalent to a PDF, 

> I believe). 

> 


> - Tom, N5EG 
> 


73' Alexander DL8AAU 

From mcdermot@eagle.aud.alcatel.com Wed Mar 08 09:13:46 1995 

Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with ESMTP id JAAQ8003 for <hfsig@tapr.org>; Wed, 8 Mar 1995 
09:13:42 -0600 

Received: by janus@1.aud.alcatel.com id <20587>; Wed, 8 Mar 1995 09:10:39 -0600 
Date: Wed, 8 Mar 1995 09:10:30 -0600 


From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

To: hfsig@tapr.org 

Subject: Re: HF Channel Simulator 

Message-Id: <95Mar8.091039cst.20587@janus01.aud.alcatel.com> 


I have performed some analysis on the question of the shape of 
the tap-gain functions. I now understand Alexander's original question. 
My previous statements about the filter shape are not correct. Here's 
what I did, and the results. 


1. Generated a real-valued random number stream using gaussian-distributed 
random number, and calculated power spectral density (PSD) using two methods, 
Fourier transform of autocorrelation integral, and using Welsh's periodogram. 
Both give white PSD (ie: flat PSD vs. frequency). 


2. Generated a complex-valued random number stream, with I- and Q- components 
generated by two independent gaussian-distributed random number sequences. 
Using both methods to compute PSD, as above, the PSD was white. The 
amplitude PDF is Rayleigh, the phase PDF is uniform. 


3. Designed an IIR LPF filter, 2nd order Butterworth, with corner frequencies 
of 0.1, and ©.25. Then filtered the random sequence generated in step 2 with 
this filter. 


4. Calculated the PSD of the filtered signal from step 3 with both methods. 
Each gives a lowpass PSD resembling the Butterworth filter response curve. 
This corresponds to the tap-gain spectrum, if one looks at the double-sided 
spectrum. 


Notes from observation of the filter shape of the Butterworth responses: 


1st order filter has poor roll-off, the shape does not look like a gaussian 
roll-off. Lot of higher frequency energy. This results in tap-gain spectrum 
that does not look gaussian, ie: too much energy too far away from the 

center frequency -> pessimistic results. 


2nd order Butterworth LPF gives very nice roll-off characteristic, closely 
matching gaussian response. It's slightly distorted at low frequency, good 
match in transition region and cut-off region. If one were to generate the 
double-sided spectrum, this would give a result matching the gaussian 
spectrum roll-off, except that the part in the very center would be squashed 
down a little (flat across the top, instead of bullet-nosed). 


3rd order Butterworth LPF gives a spectrum with a too-sharp roll-off. This 
would be too rectangular- as compared to the gaussian curve. 


So, the conclusion I would reach is that the 2nd order Butterworth is 
a pretty good approximation to the gaussian tap-gain spectrum shape. 


- Tom, N5EG 


PS: This discussion over the last week on hfsig has been extremely 
educational. Thanks! 


From FORRERJ@frl.orst.edu Thu Mar 09 16:08:19 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id QAA15905 for 
<HFSIG@tapr.org>; Thu, 9 Mar 1995 16:08:12 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id GAA18429 for <HFSIG@tapr.org>; Thu, 9 Mar 1995 06:44:48 
-0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 9 Mar 95 14:04:18 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 9 Mar 95 14:03:53 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Thu, 9 Mar 1995 14:03:44 PST8PDT 
Subject: Annual meeting update 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <41F3CFA3CF9@frl.orst.edu> 
Hi All, 


Thought that I would welcome all those that joined us after 
the TAPR annual meeting. 


For those that did not have the opportunity to attend - it was 
quite interesting. Was my first time. I was taken with the richness 
in diversity of fields of interests and capabilties of participants. 


There was a lot of emphasis on DSP. Bob Stricklin made a valiant 

effort to stimulate the discussion in the DSP developer's simposium, 
however, it quickly evolved into a "wishlist for digital radio 

features". In my humble opinion, the opportunity was lost to bring together 
those that are actually developing DSP applications. It was a large 
audience, evidently with lots of different expectations, just my opinion 
that there were too many with other interests that overwhelmed 

the purpose of the meeting. 


Tom McDermit, N5EG, made an outstanding presentation on channel 
characterization - I certainly enjoyed his approach and 
learned a few things. I am looking forward to Tom's book. 


Saturday afternoon, we had an HFSIG meeting that was attended by 

15 - 20 folks. This meeting paralled with another on TCP/IP, so 

guess we had the *REAL* HF digital enthusiasts together. I presented 

a summary of recent activities that included: the work on the HF channel 
simulator and alternate modulation schemes. I indicated that our efforts 
are focussed on a) methods for high speed communications suitable for 


networking applications, and b) low speed, very robust communications to 
operate in adverse conditions. There is a distinction beween these. I 
also discussed some of the results on improving crest factor. It was 
evident that the contributions of this SIG was followed by many, and 
with interest. Thanks to all of you for making this possible. 


The dinner presentation was an energetic talk by Paul Schuch on SETI. 


Sunday morning was time for Phil Karn's, KA9Q, exceptionally good 
presentation on error-control coding. It was an ejoyable experience, non- 
mathematical, however, with enough depth to get the point across. The 
message was that there is no free lunch - everything is a compromise, the 
main tradeoffs being bandwidth and power. Block codes works better 

when block size is larger. Convolutional codes are more computationally 
expensive, however, yields somewhat better coding gain. Softening up the 
decisions at the descriminator helps a lot. At it simplest, erasure coding 
is a start. However, multiple levels of decision codes does wonders. The 
combination of inner/outer codes was shown to be the ultimate, however, 
probably also the most demanding as far as computations are concerned. 
Phil's talk contained numerous interesting asides of how professionals 
does it on the deep space projects, i.e., how to get the message across 
when the spacecraft's big antenna is not working as it should. 


Sunday afternoon, Bob Stricklin, and Tom McDermit presented a wealth of 
useful information for aspiring DSP-93 programmers. It was a lot of fun 
listening to questions and answers - everyone got their money's worth. 


Personally, I thought that it was a worthwhile experience. The board, 
especially Greg Jones, deserves credit for a job well done. The organizers 
also did an outstanding job to make us all feel welcome. It was a wonderful 
auditorium and everything ran like clockwork. 


Thanks all, 
73's 
Johan, KC7WW 


From techman@ace.com Fri Mar 10 02:03:56 1995 

Received: from uu10.psi.com (uu10.psi.com [38.8.4.2]) by dingus.n5lyt.datarace.com 

(8.6.10/8.6.9) with SMTP id CAA18084 for <hfsig@tapr.org>; Fri, 10 Mar 1995 

02:03:30 -0600 

Received: from uu0924.UUCP by uu10.psi.com (5.65b/4.0.061193-PSI/PSINet) via UUCP; 
id AA14135 for ; Fri, 10 Mar 95 02:55:40 -@500 

Date: Fri, 10 Mar 95 02:33:55 EST 

From: techman@ace.com (Techman) 

Subject: info 

Message-Id: <9503100233.0.UUL1.3#25274@ace. com> 

To: hfsig@tapr.org 


subscribe 
From faunt@netcom.com Fri Mar 10 14:24:01 1995 


Received: from netcom2.netcom.com (netcom2.netcom.com [192.100.81.108]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id 0AA20491 for 
<hfsig@tapr.org>; Fri, 10 Mar 1995 14:22:54 -0600 
Received: by netcom2.netcom.com (8.6.10/Netcom) 
id JAA20975; Fri, 10 Mar 1995 09:15:42 -0800 
Date: Fri, 10 Mar 1995 09:15:42 -0800 
From: faunt@netcom.com (Doug Faunt N6TQS 510-655-8604) 
Message-Id: <199503101715.JAA20975@netcom2.netcom. com> 
To: hfsig@tapr.org 
Subject: PacTOR II? 


Are there any references available on PacTOR II? 

How does it differ from PacTOR? 

73, doug 

From mcdermot@eagle.aud.alcatel.com Fri Mar 10 15:26:28 1995 

Received: from aud.alcatel.com ([198.64.191.3]) by dingus.n5lyt.datarace.com 
(8.6.10/8.6.9) with ESMTP id PAA21304 for <hfsig@tapr.org>; Fri, 10 Mar 1995 
15:26:25 -0600 

Received: by janus@1.aud.alcatel.com id <20555>; Fri, 10 Mar 1995 15:23:07 -0600 
Date: Fri, 10 Mar 1995 15:22:50 -0600 

From: mcdermot@eagle.aud.alcatel.com (Tom Mcdermott) 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:306] PacTOR II? 

Message-Id: <95Mar10.152307cst.20555@janus01.aud.alcatel.com> 


Are there any references available on PacTOR II? 
How does it differ from PacTOR? 
73, doug 


VV VV 


The ADRS Journal for Jan/Feb/Mar has information on Pactor II. 
I have Jan and Feb articles - Jan talks about two-tone DPSK and convolutional 
coding. Feb issue says little useful. Mar issue is supposed to say more, 
but am waiting for it. 


So far, it's pretty vague about the exact format. Requires unit 
with a 56000 series DSP and a 68000 series general microprocessor. 


I'm guessing it will say that it is two-tone DBPSK 200-baud per tone, 
with rate=1/2 k=9 convolutional coding, and raised-cosine baseband filtering. 
But we'll have to wait and see. 


- Tom, N5EG 
From karn@qualcomm.com Fri Mar 10 15:41:02 1995 
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id PAA21410 for 
<hfsig@tapr.org>; Fri, 10 Mar 1995 15:40:59 -0600 
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id NAAQ0427; 
Fri, 10 Mar 1995 13:40:10 -0800 
Date: Fri, 10 Mar 1995 13:40:10 -0800 
From: Phil Karn <karn@qualcomm. com> 
Message-Id: <199503102140.NAAQ0427@servo.qualcomm. com> 
To: hfsig@tapr.org 


In-reply-to: <32B761B3EE3@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 
Subject: Thoughts on HF channel simulation 


Everything I read and hear says that HF channels are really hard to 
model and simulate realistically. But a repeatable simulation is 
really important to have if you want to do controlled tests and 
comparisons. 


Would it be possible to probe a real HF channel, record its response 
digitally, and then use that information in offline simulations that 
could be replayed as often as desired? 


Broadband impulses would make good channel probing signals. Where's 
the woodpecker now that we need it? :-) 


Phil 


From rick@itron-ca.com Fri Mar 10 21:42:40 1995 

Received: from itron-ca.com ([204.30.20.2]) by dingus.n5lyt.datarace.com 

(8.6.10/8.6.9) with ESMTP id VAA23223 for <hfsig@tapr.org>; Fri, 10 Mar 1995 

21:41:22 -0600 

Received: (from audit@localhost) by itron-ca.com (8.6.9/8.6.9) id TAAQ7780; Fri, 

10 Mar 1995 19:37:29 -0800 

Received: from unknown(204.30.20.118) by gate.itron-ca.com via smap (V1.3mjr) 
id smaQ07778; Fri Mar 10 19:36:54 1995 

Date: Fri, 10 Mar 95 19:23:32 PST 

From: "Richard W. D. Booth" <rick@itron-ca.com> 

Subject: RE: [HFSIG:308] Thoughts on HF channel simulation 

To: hfsig@tapr.org 

X-Mailer: Chameleon - TCP/IP for Windows by NetManage, Inc. 

Message-ID: <Chameleon.4.01.950310193656.rick@rick.itron-ca.com> 

MIME-Version: 1.0 

Content-Type: TEXT/PLAIN; charset=US-ASCII 


>Everything I read and hear says that HF channels are really hard to 

>model and simulate realistically. But a repeatable simulation is 

>really important to have if you want to do controlled tests and 
>comparisons. 

> 

>Would it be possible to probe a real HF channel, record its response 
>digitally, and then use that information in offline simulations that 

>could be replayed as often as desired? 

> 

>Broadband impulses would make good channel probing signals. Where's 

>the woodpecker now that we need it? :-) 

> 

>Phil 

> 

Good question but may have some difficulties: 

1. Broadband impulses are a good way to make the measurements as long as the 
receiving "bandwidth" is large enough so that it does not distort the measurments. 
This includes the antenna and front end filters. Not to mention the legal 


issues...hmmm 

2. Narrow band or CW probing has the following problems. 

Presumably the amplitude and phase of the incoming signal could be traccked if the 
receiver LOs were stable enough. Measurement of doppler shift would require 
knowing 

the stability at both the transmit and receive ends... 

3. Given the above CW measurment could be made then the results must be extended 
over the signal bandwidth of interest. Assume a flat fading model where the 
measurement is assumed to apply to all frequencies in the band of interest? 
Multitone probes could be used and the different phase and amplitude 
characteristics 

used to synthesize a time varying filter. Sounds tough. 


No doubt a repeatable model is necessary. This must be availble to anyone 
interested 

in developing both hardware and software for the solution of the problem. Fixing 
the 

"standard" channel model is likely the only way non subjective evaluations will be 
achievable...somehow the BS has got to be separable from the facts!!! 

Rick Booth 

w6nzk 


From kurpiers@zeus.uet.e-technik.th-darmstadt.de Sat Mar 11 05:39:19 1995 
Received: from rs2.hrz.th-darmstadt.de (rs2.hrz.th-darmstadt.de [130.83.22.63]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id FAA24879 for 
<hfsig@tapr.org>; Sat, 11 Mar 1995 05:39:15 -0600 
Received: from zeus.uet.e-technik.th-darmstad (zeus.uet.e-technik.th-darmstadt.de) 
by rs2.hrz.th-darmstadt.de with SMTP id AA29048 

(5.65c/IDA-1.4.4 for <hfsig@tapr.org>); Sat, 11 Mar 1995 12:35:40 +0100 
Received: from hades.uet.e-technik.th-darmsta (hades.uet.e-technik.th-darmstadt.de 
[130.83.18.78]) by zeus.uet.e-technik.th-darmstadt (8.6.4/8.6.4) with ESMTP id 
MAA16023 for <hfsig@tapr.org>; Sat, 11 Mar 1995 12:35:38 +0100 
From: Alexander Kurpiers <kurpiers@zeus.uet.e-technik.th-darmstadt.de> 
Received: from localhost (kurpiers@localhost) by hades.uet.e-technik.th-darmstad 
(8.6.4/8.6.4) id MAA16623 for hfsig@tapr.org; Sat, 11 Mar 1995 12:33:04 +0100 
Message-Id: <199503111133 .MAA16623@hades.uet.e-technik.th-darmstad> 
Subject: RE: Thoughts on HF channel simulations 
To: hfsig@tapr.org 
Date: Sat, 11 Mar 1995 12:33:04 +0100 (MEZ) 
X-Mailer: ELM [version 2.4 PL24] 
Mime-Version: 1.0 
Content-Type: text/plain; charset=US-ASCII 
Content-Transfer-Encoding: 7bit 
Content-Length: 472 


Hi! 
This kind of research was done in the early 70's by Watterson et. al. and 
lead to a widely accepted model which is described in the CCIR report 


549-3 (1990). The original paper is: 


Watterson, C.C., Juroshek, J.R. and Bensema, W.D., "Experimental 


confirmation of an HF channel model", IEEE Trans. Comm. Tech., COM-18, 
1970, pp. 792-803. 


This model covers ionosperic transmissions with discrete Rayleigh fading 
paths and is found to be very realistic. 


73' Alexander 
From bobs@tcet.unt.edu Sat Mar 11 11:29:55 1995 
Received: from tcet.unt.edu (tcet.unt.edu [129.120.20.191]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA25784 for 
<hfsig@tapr.org>; Sat, 11 Mar 1995 11:29:53 -0600 
Received: by tcet.unt.edu (5.61-AIX-1.2/1.0) 
id AA148471 (for hfsig@tapr.org, from bobs/bobs@tcet.unt.edu); Sat, 11 Mar 95 
11:25:14 -0600 
From: bobs@tcet.unt.edu (Bob Stricklin) 
Message-Id: <9503111725.AA148471@tcet.unt.edu> 
Subject: Digital Test Files 
To: hfsig@tapr.org 
Date: Sat, 11 Mar 95 11:25:14 CST 
In-Reply-To: <199503111133 .MAA16623@hades.uet.e-technik.th-darmstad>; from 
"Alexander Kurpiers" at Mar 11, 95 05:45:41 am 
X-Mailer: ELM [version 2.4dev PL17] 


It should be possible to code the Waterson model in such a way that a 
DSP unit would produce a standard test pattern. This test pattern could 
then be transmitted and recorded by a second HF station equipped with 
DSP so the pattern can be digitally recorded and stored. Then the file 
could be placed on an FTP site as a test data block. I think this is 
what Phil wanted. I have been thinking about the same thing. Actually I 
would like to have a collection of digitally recorded files for all the 
typical modulation or encoding methods used today. Then you could do 
modeling and testing of filter code in EXCEL. 


The TAPR DSP-93 should work will in this applaction. 
Bob Stricklin, N5BRG 


From fmitchell@rdcclink.rd.qms.com Sun Mar 12 16:34:33 1995 
Received: from gatekeeper.qms.com (gatekeeper.imagen.com [161.33.3.1]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA32744; Sun, 12 Mar 1995 
16:34:29 -0600 
From: fmitchell@rdcclink.rd.qms.com 
Received: from imagen.sclara.qms.com (imagen.imagen.com) by gatekeeper.qms.com 
(4.1/SMI-4.1) 
id AAQ7864; Sun, 12 Mar 95 14:30:33 PST 
Received: from sun470.rd.qms.com by imagen.sclara.qms.com (4.1/SMI-4.1) 
id AAQ1153; Sun, 12 Mar 95 14:30:32 PST 
Received: from rdcclink.rd.qms.com by sun470.rd.qms.com (4.1/SMI-4.1) 
id AA15583; Sun, 12 Mar 95 16:27:27 CST 
Received: from ccMail by rdcclink.rd.qms.com 
id AA795054599 Sun, 12 Mar 95 16:29:59 CST 
Date: Sun, 12 Mar 95 16:29:59 CST 
Message-Id: <9502127950.AA795054599@rdcclink.rd.qms.com> 


To: netsig@tapr.org, bbssig@tapr.org, hfsig@tapr.org 
Return-Receipt-To: fmitchell@rdcclink.rd.qms.com 
Subject: unsubscribe 


unsubscribe fmitch@rd.qms.com 
subscribe fmitch@maf.mobile.al.us 
From wtb@partyline.org Sun Mar 12 19:22:49 1995 
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id TAAQ0788 for 
<hfsig@tapr.org>; Sun, 12 Mar 1995 19:22:47 -0600 
From: wtb@partyline.org 
Received: from partyline.org by uustar.starnet.net with UUCP id AA16724 
(5.67b/IDA-1.5 for hfsig@tapr.org); Sun, 12 Mar 1995 19:08:35 -0600 
Received: by partyline.org 
id OQV4E004 Sun, 12 Mar 95 19:07:23 -0600 
Message-Id: <9503121907.0QV4E00@partyline.org> 
Organization: Party Line Entertainment Network 
X-Mailer: TBBS/PIMP v3.29 
Date: Sun, 12 Mar 95 19:07:23 -0600 
Subject: HF Simulations 
To: hfsig@tapr.org 


QEX, Dec '94, page 9, KE4BAD discusses two HF simulations you might 
want to consider. Bill NOLIK 6219146 
reply wtb@partyline.org 
From FORRERJ@frl.orst.edu Mon Mar 13 10:33:14 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAAQ5271 for 
<HFSIG@tapr.org>; Mon, 13 Mar 1995 10:33:10 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO4402 for <HFSIG@tapr.org>; Mon, 13 Mar 1995 
01:08:49 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 13 Mar 95 8:28:28 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 13 Mar 95 8:28:04 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Mon, 13 Mar 1995 08:27:59 PST8PDT 
Subject: HFSIG Quaterly report 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <479A6CAO084F@frl.orst.edu> 
Hi All, 
Here is a copy of HFSIG quaterly report. Please let me know 


of any typo's, misspellings or items of interest that I missed 
else that is how it goes into PSR. 


73's 


Johan 


FEEFEEFEEEEFEAFETEEEEEEEFEAFELEEFEEEEEFEAEETEEEEEEEPEAFETEAEEEPE PEATE 
HFSITG QUARTERLY SUMMARY: MARCH 1995 


Judging from comments expressed at the recent TAPR annual 
meeting, the activities of HFSIG are followed by many and found 
to contain interesting and useful material. HF digital is one 
instance where technical advances and its adoption by the amateur 
community, can be made with relative ease. Recent examples of 
this are CLOVER II, G-TOR, and PACTOR II. Many fields in amateur 
radio do not allow this degree of flexibility in adopting new 
ideas and standards. The challenge of the HF channel offers a 
unique opportunity to explore and bring together a mix of theory, 
hardware, and software. Thanks to all your contributions that 
makes this possible. 


Activities on HFSIG included several topics of interest: 
HF Channel Simulator, 
HF Modem Technology, 
Error-Control Coding. 


HF Channel Simulator 


An HF channel simulator is an essential tool for HF modem 
evaluation. For example, comparing TNC's or testing and tuning 
algorithms. HFSIG's simulator effort has been based on a model of 
HF propagation developed by Watterson et. al. (1). Simulating the 
HF channel is a very complex subject - computer models such as 
IONCAP simulates the nature of the ionosphere from input 
parameters such as sunspot data, day and time for the year, 
frequency of operation, also magnetic and geographical location. 
For our purpose, however, a much simpler approach is followed. A 
bandwidth-limited, stationary model with operational parameters 
defined by CCIR recommendations (2) is used. This model is based 
on work by the Watterson group using actual on-the-air broadband 
transmissions and found statistically accurate. This is a well- 
known method used for evaluation and testing purposes. For a 
description of an actual implementation of such a model, please 
see reference (3). 


Recently, the interpretation of how to generate appropriate 
fading functions was discussed by Tom McDermott and Alexander 
Kurpiers. These functions have to represent two independent 
complex bivariate Gaussian ergodic random processes, each with 
zero mean and independent real and imaginary components with 
equal R.M.S. values that produce Rayleigh fading. 


Contributors for this discussion: 


Rick Whiting, WOTN, 

Barry Buelow, WORJT, 

Eric Silbaugh, N2NNP, 

Glen Worstell, KGOT, 

Rick Booth, W6NZK, 

Jon Bloom, KE3Z, 

Hugh Shane, N7UAX, 

Tom McDermott, N5EG, 
Alexander Kurpiers, DL8AAU. 


HF Modem Technology 


Two objectives are evident: A) High speed modems for 
eventual application over HF-based networks. B) Robust modems for 
use under adverse conditions. These two objectives possibly 
require different approaches and tradeoffs have to be made. 


Several promising approaches have been proposed. Orthogonal 
signaling schemes were suggested by Alan Bloom and Phil Karn. 
These schemes define multiple signaling channels spaced apart in 
frequency such that these are essentially independent. Occupied 
bandwidth varies depending on the number of channels and the 
symbol rate. 


The family of MIL-STD-188, 16 and 39 parallel-tone modems, 
are good examples of multi-tone modems that are already available 
as commercial products, while ITA21, 6-tone, and ITA52, 12-tone 
Piccolo modems are examples of implementation of the MFSK 
approach. Ongoing work by Paul Russell and Pawel Jalocha 
continues the parallel approach, whereas Adrian Nash is pursuing 
the MFSK approach. Extensive literature is available on MFSK - 
reference (4) is a good place to start. 


Waveform synthesis for multi-tone signals was reviewed to 
reduce extreme amplitude situations, i.e., noise-like spikes. 
Eric Silbaugh has been looking into these using computer 
simulation. Barry McLarnon pointed us to appropriate literature 
on the subject. Please refer to reference (5) for further 
details. 


Contributors in this discussion included: 


Rick Whiting, WOTN, 
Walt DuBose, K5YFwW, 
Phil Karn, KA9Q, 

Hugh Shane, N7UAX, 
Barry McLarnon, VE3JR, 
Alan Bloom, N1AL, 
Adrian Nash, G4ZHZ, 


Charles Brain, G4GUO, 

Kok Chen, AA6TY, 

Rolf Sommerhalder, HB9CWP, 
Frode Weierud, F/LA2RL, 
Pawel Jalocha, (S53??), 
Paul Russell (non-ham). 


Error-Control Coding 


The purposes of error-control coding for future HF modems 
are evident - dealing with fading, burst errors, interference and 
power considerations. Phil Karn has been a regular contributor 
and explained how best to employ block, convolutional, and 
combined clock/convolutional methods. Pawel Jalocha suggested a 
novel Hamming code for use with his experimental multi-tone 
modem. Phil has promised to contribute his efforts of an advanced 
convolutional coder that would ideally be suited for our future 
HF digital work. We are looking forward to this. 


Contributors in this discussion: 


Phil Karn, KA9Q, 
Pawel Jalocha. 


General 


A growing library of code examples is available in the HFSIG 
upload area: 


ftp.tapr.org tapr/SIG/hfsig/upload 


Example code for the HF simulator, experimental parallel 
modem, and error-control codes are available. In addition, DSP 
code for AMTOR/PACTOR using a DSP sound card, also W9GR ported 
denoising code is available for experimental purposes. 


Important notice: 


As scribe/HFSIG chair person, this probably will be my last 
contribution for a while. Life's realities, in my case, my Ph.D 
work, has required that most everything else must be put on hold. 
HFSIG thus require assistance in this regard. Please contact Greg 
if you like to volunteer to help out. This is a very capable and 
nice group of people to work with. 


Thanks to each and all for participating, good luck, and 
keep up the good work. 
Johan Forrer 


(KC7WW) 
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From FORRERJ@frl.orst.edu Mon Mar 13 10:48:39 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAAQ5368 for 
<HFSIG@tapr.org>; Mon, 13 Mar 1995 10:48:35 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO4565 for <HFSIG@tapr.org>; Mon, 13 Mar 1995 
01:24:14 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Mon, 13 Mar 95 8:43:53 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 13 Mar 95 8:43:35 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Mon, 13 Mar 1995 08:43:26 PST8PDT 
Subject: HF Channel simulator 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <479E8F363CF@frl.orst.edu> 
Greetings, 


I noticed some recent activities on the HF Simulator topic - good to hear 
the new ideas. 


My $0.02: I think I hear three different things. 


1) Bob needs a standard "test recording" of different signals for purposes 
of tuning and developing filters. 


2) Phil (I think) is interested in knowing the channel's actual transfer 


function. Knowing this, one may use adaptive techniques. This is 

not easy as the channel is very dynamic, but I can see that if a form of 
training sequence is sent ahead of a data transmission by the ISS, and the 
IRS does the proper analysis, it may signal this back to the ISS 

for taking appropiriate action. 


3) Modem evaluation: This is where we want to actually take a baseband 
Signal from a modem under test, play all the tricks that the channel would 
do to the signal (multipath distortion, flat/selective fading, etc) and 
pass this modified signal to another modem to decode. I think it is 
understood that this cannot be done with a pre-recorded data signal. You 
would want to have the ability to signal message content at will such to 
obtain a good statistical representative sample of how well the modem 
performs. 


The Watterson model that we are working on will perform (3) above. 
I do, however, see that (1) and (2) also have merit. 


If someone want to take this on, how about start making recordings in 
".,wav" format and upload it. This way we can can play with it a little. 


Hope this helps. 
73's 


Johan, KC7WW 

From aherhld@iaccess.za Mon Mar 13 14:03:31 1995 

Received: from minnie.iaccess.za (minnie.iafrica.com [196.7.142.132]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id OAA06349 for 

<hfsig@tapr.org>; Mon, 13 Mar 1995 14:03:23 -0600 

Received: from slipper116195.iaccess.za by minnie.iaccess.za with smtp 
(Smail3.1.28.1 #5) id mOroGGg-0007LdC; Mon, 13 Mar 95 21:59 GMT+0200 

Message-Id: <m0roGGg-0007LdC@minnie.iaccess.za> 

Sender: <aherhld@minnie.iafrica.com> 

From: "Andries Herholdt" <aherhld@iaccess.za> 

To: hfsig@tapr.org 

Date: Mon, 13 Mar 1995 21:47:16 +0000 

Subject: Re: Digital Test Files 

Priority: normal 

X-mailer: Pegasus Mail/Windows (v1.22) 


On Sat, 11 Mar 1995 , Bob Stricklin wrote : 


> what Phil wanted. I have been thinking about the same thing. Actually I 
> would like to have a collection of digitally recorded files for all the 
> typical modulation or encoding methods used today. 


Perhaps you are familiar with Klingenfuss Publication's CD's ? They 
are CD recordings of many typical HF modulation types including many 
digital ones. Perhaps one could convert them to data format somehow. 
The most elegant method would be to write a program ( Visual Basic? 

) to read the data straight off the disk using a CDROM. A less 
elegant way might be to record it straight off play it back through a 


sound card and get hold of the data there. Of course, Klingenfuss 
would have to give their blessing to such an endeavour ! 


One of my clients ( I am a freelance engineer ) have done what you 
suggest; they have a library on 1Gbyte laser disks of many signals 
recorded down here ( za = South Africa ), which they use for 

comms research. They might even be persuaded to part with it, but 
probably not for free :(. ( nothing in it for me BTW ). 


Perhaps I will be forgiven for slipping in a question at this point 
that is slightly off the topic ? At the moment I am working on some 
data decoding software and one of the topics that came up was a 32 
-tone version of MFSK that Klingenfuss calls CIS Piccolo and 
apparently also is known as CROWD36. I can manage to extract the raw 
symbols, but of course the alphabet is the main problem. I was 
wondering : does anyone have any info on this, or could you point me 
in the direction of an information source ? 


Thanks in advance, 
Andries. 
Andries Herholdt 
aherhld@iaccess.za 
From wtb@partyline.org Mon Mar 13 19:37:30 1995 
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id TAAQ8081 for 
<hfsig@tapr.org>; Mon, 13 Mar 1995 19:37:27 -0600 
From: wtb@partyline.org 
Received: from partyline.org by uustar.starnet.net with UUCP id AA23920 
(5.67b/IDA-1.5 for hfsig@tapr.org); Mon, 13 Mar 1995 19:21:19 -0600 
Received: by partyline.org 
id OR5FQ005 Mon, 13 Mar 95 19:19:37 -0600 
Message-Id: <9503131919.OR5FQOO0@partyline.org> 
Organization: Party Line Entertainment Network 
X-Mailer: TBBS/PIMP v3.29 
Date: Mon, 13 Mar 95 19:19:37 -0600 
Subject: access 
To: hfsig@tapr.org 


help. 
wtb@partyline.org 
From wtb@partyline.org Mon Mar 13 19:37:33 1995 
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id TAAQ8087 for 
<hfsig@tapr.org>; Mon, 13 Mar 1995 19:37:29 -0600 
From: wtb@partyline.org 
Received: from partyline.org by uustar.starnet.net with UUCP id AA23915 
(5.67b/IDA-1.5 for hfsig@tapr.org); Mon, 13 Mar 1995 19:21:17 -0600 
Received: by partyline.org 
id OR5F4004 Mon, 13 Mar 95 19:19:36 -0600 
Message-Id: <9503131919.OR5F400@partyline.org> 


Organization: Party Line Entertainment Network 
X-Mailer: TBBS/PIMP v3.29 

Date: Mon, 13 Mar 95 19:19:36 -0600 

Subject: HF simulation 

To: hfsig@tapr.org 


Can someone tell mee were to find out what a .wav file is? How 
is it put together and how is it played from the computer?: 
Bill NOlik reply wtb@partyline.org 
From bstrick@tenet.edu Mon Mar 13 23:09:48 1995 
Received: from Leslie-Francis.tenet.edu (Leslie-Francis.tenet.edu [198.213.2.9]) 
by dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id XAA09495 for 
<hfsig@tapr.org>; Mon, 13 Mar 1995 23:09:46 -0600 
Received: (from bstrick@localhost) by Leslie-Francis.tenet.edu (8.6.9/8.6.9) id 
XAA16718 for hfsig@tapr.org; Mon, 13 Mar 1995 23:05:44 -0600 
From: Bob Stricklin <bstrick@tenet.edu> 
Message-Id: <199503140505.XAA16718@Leslie-Francis.tenet.edu> 
Subject: Re: [HFSIG:316] Re: Digital Test Files 
To: hfsig@tapr.org 
Date: Mon, 13 Mar 1995 23:05:42 -0600 (CST) 
In-Reply-To: <mOroGGg-0007LdC@minnie.iaccess.za> from "Andries Herholdt" at Mar 
13, 95 02:15:33 pm 
X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 847 


According to Andries Herholdt: 

> 

> 

Thanks for your comments. I think it will be easier to make my own files. 
Sounds like the others may be a little hard to find. Also I have a better 
idea what is required to generate the files from a radio with the DSP-93. 


Perhaps I will be forgiven for slipping in a question at this point 
that is slightly off the topic ? At the moment I am working on some 
data decoding software and one of the topics that came up was a 32 
-tone version of MFSK that Klingenfuss calls CIS Piccolo and 
apparently also is known as CROWD36. I can manage to extract the raw 
symbols, but of course the alphabet is the main problem. I was 
wondering : does anyone have any info on this, or could you point me 
in the direction of an information source ? 


VV VV VV VV 


Sorry, I can not help you on this. 
Bob Stricklin, N5BRG 


From nash@camail.ca.nmp.nokia.com Tue Mar 14 07:02:25 1995 

Received: from noknic.nokia.com (noknic.nokia.com [131.228.6.10]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAA11808 for 
<hfsig@tapr.org>; Tue, 14 Mar 1995 07:02:20 -0600 


Received: from mgw.nmp.nokia.com (mgw.nmp.nokia.com [131.228.233.85]) by 

noknic.nokia.com (8.6.9/8.6.9) with SMTP id OAA23492 for <hfsig@tapr.org>; Tue, 14 

Mar 1995 14:57:56 +0200 

Message-Id: <199503141257 .0AA23492@noknic. nokia. com> 

Received: from camail.ca.nmp.nokia.com by mgw.nmp.nokia.com with SMTP 
(1.38.193.4/16.2) id AAQ6356; Tue, 14 Mar 1995 07:54:30 -0500 

Received: from bashful.ca.nmp.nokia.com (bashful) by camail with SMTP 
(1.37.109.14/16.2) id AAQ07685892; Tue, 14 Mar 1995 12:58:12 GMT 

Date: Tue, 14 Mar 1995 12:58:12 GMT 

From: Adrian Nash <nash@camail.ca.nmp.nokia.com> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:316] Re: Digital Test Files 

Cc: nash@camail.ca.nmp.nokia.com 


Hello Andries 


>Perhaps I will be forgiven for slipping in a question at this point 
>that is slightly off the topic ? At the moment I am working on some 
>data decoding software and one of the topics that came up was a 32 
>-tone version of MFSK that Klingenfuss calls CIS Piccolo and 
>apparently also is known as CROWD36. I can manage to extract the raw 
>symbols, but of course the alphabet is the main problem. I was 
>wondering : does anyone have any info on this, or could you point me 
>in the direction of an information source ? 


I presume that CIS Piccolo is pretty much the same as UK FCO Piccolo. It would 
seem reasonable to assume that the alphabet is the same as Cyrillic radio 
teletype using the NULL character as a 3rd shift. I think Mr Klingenfuss has 
described this alphabet in his book. 


Thought for the day : I wonder if the UK Foreign Offices' old LA2028 Piccolos 
ended up in the CIS??? :-) 


Regards 


Adrian G4ZHZ 
From FORRERJ@frl.orst.edu Tue Mar 14 10:28:12 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA13658 for 
<hfsig@tapr.org>; Tue, 14 Mar 1995 10:28:09 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA11249 for <hfsig@tapr.org>; Tue, 14 Mar 1995 
01:03:32 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Tue, 14 Mar 95 8:23:14 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Tue, 14 Mar 95 8:22:47 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Tue, 14 Mar 1995 08:22:45 PST8PDT 
Subject: Re: [HFSIG:318] HF simulation 
Priority: normal 


X-mailer: PMail v3.0 (Ria) 
Message-ID: <49190E670A6@frl.orst.edu> 


Bill, 


A good place to look for programs and some documentation on .wav files are 
in the SIMTEL archives ( £tp to: oak.oakland.edu) and look in the 
windows/sounds directory for a collection of sound record/playback 
programs. 


If you still have a question, I'll be happy to post the format. 
73's 


Johan 
From bm@lynx.ve3jf.ampr.org Tue Mar 14 22:27:56 1995 
Received: from hydra.carleton.ca (hydra.carleton.ca [134.117.12.18]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id WAA18240 for 
<hfsig@tapr.org>; Tue, 14 Mar 1995 22:27:53 -0600 
Received: from lynx.ve3jf.ampr.org (root@lynx.ve3jf£.ampr.org [44.135.96.100]) by 
hydra.carleton.ca (8.6.9/8.6.9) with SMTP id XAA31198 for <hfsig@tapr.org>; Tue, 
14 Mar 1995 23:23:37 -0500 
Received: by lynx.ve3jf.ampr.org (Linux Smail3.1.28.1 #14) 
id mOrokcY-0002pQC; Wed, 15 Mar 95 04:23 GMT 
Message-Id: <mOrokcY-0002pQC@lynx.ve3j£.ampr.org> 
From: bm@lynx.ve3j£.ampr.org (Barry McLarnon VE3JF) 
Subject: Re: [HFSIG:308] Thoughts on HF channel simulation 
To: hfsig@tapr.org 
Date: Wed, 15 Mar 1995 04:23:40 +0000 (GMT) 
In-Reply-To: <199503102140.NAAQ0427@servo.qualcomm.com> from "Phil Karn" at Mar 
10, 95 03:42:31 pm 
X-Mailer: ELM [version 2.4 PL23] 
Content-Type: text 
Content-Length: 2006 


Everything I read and hear says that HF channels are really hard to 
model and simulate realistically. But a repeatable simulation is 
really important to have if you want to do controlled tests and 
comparisons. 


Would it be possible to probe a real HF channel, record its response 
digitally, and then use that information in offline simulations that 
could be replayed as often as desired? 


VV VV VV VV 


Definitely. I brought this up briefly with Johan at the TAPR meeting. 
About 10 years ago, when I was involved with HF stuff at my place of 
work, we had an HF channel simulator with this capability built under 
contract. The simulator used the TMS32010, shortly after that chip was 
first introduced. Separate from the simulator was a PRBS probe 
generator, clocked such that the main lobe would fit comfortably in the 
passband (~2 kHz) of an ssb transmitter. This was transmitted over 
various HF channels, and the baseband receiver output (with AGC off) 
recorded on an instrumentation tape recorder. Nowadays, of course, 


you'd use your sound card and store the received signal on your hard 
disk. The tape could then be played back into the simulator, where the 
signal was digitized and correlated in real time against a stored 
replica of the PRBS obtained from a back-to-back connection of the 
transmitter and receiver. The impulse response estimates from the 
correlator were then used to adjust the tap weights of the simulator in 
the main signal path. This is very convenient, since it allows you to 
reproduce the actual conditions on a real channel in a completely 
repeatable fashion, with no dependence on the modulation format of the 
system(s) under test. 


I'll see if I can dig up some docs on the thing... I don't think there's 
anything proprietary about it - it was a "one of" development and was 
never made into a commercial product. 


> Phil 


Barry 


Barry McLarnon VE3JF/VA3TCP 

Ottawa Amateur Radio Club Packet Working Group 

Email: bm@hydra.carleton.ca or bm@lynx.ve3jf£.ampr.org 

From karn@qualcomm.com Wed Mar 15 14:15:50 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id OAA0Q0457 for 
<hfsig@tapr.org>; Wed, 15 Mar 1995 14:15:37 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id MAA26223; Wed, 
15 Mar 1995 12:15:54 -0800 

Date: Wed, 15 Mar 1995 12:15:54 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199503152015 .MAA26223@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <479E8F363CF@frl.orst.edu> (FORRERJ@frl.orst.edu) 
Reply-To: karn@qualcomm.com 

Subject: Re: [HFSIG:315] HF Channel simulator 


>2) Phil (I think) is interested in knowing the channel's actual transfer 
>function. Knowing this, one may use adaptive techniques. This is 


Not quite. I was mainly interested in finding a way to compare 
different modems (or the same modem with experimental modifications) 
in a repeatable and realistic way. Channel simulators based on 
analytical models are repeatable, but people are concerned about their 
realism. Actual on-air testing is certainly realistic, but it can be 
hard to repeat consistently. 


So my idea was to capture an actual HF channel over a particular span 
of time (thus gaining realism) in such a way that it can be used 
repeatedly. If I could record the measured response of a real HF 
channel over some period of time, then a simulator could use it to 
corrupt and modify my test signal exactly as if it had been actually 
sent over the real channel. Even better, I would have the option of 


repeating exactly the same channel simulation sequence with a 
different modem and then comparing results on an even footing. 


Of course, you wouldn't just measure an HF channel once, you'd want to 
collect a wide variety of runs on different bands, paths and ionospheric 
conditions. 


Phil 


From karn@qualcomm.com Wed Mar 15 19:26:57 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id TAAQ2143 for 
<hfsig@tapr.org>; Wed, 15 Mar 1995 19:26:53 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id RAA26557; Wed, 
15 Mar 1995 17:27:20 -0800 

Date: Wed, 15 Mar 1995 17:27:20 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199503160127 .RAA26557@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <mOrokcY-0002pQC@lynx.ve3j£.ampr.org> (bm@lynx.ve3j£.ampr.org) 
Subject: Re: [HFSIG:322] Re: Thoughts on HF channel simulation 

Reply-To: karn@qualcomm.com 


>first introduced. Separate from the simulator was a PRBS probe 
>generator, clocked such that the main lobe would fit comfortably in the 
>passband (~2 kHz) of an ssb transmitter. This was transmitted over 
>various HF channels, and the baseband receiver output (with AGC off) 
>recorded on an instrumentation tape recorder. Nowadays, of course, 


Bingo, this is exactly what I had in mind. 


A possible alternative to the pseudo-random bit stream would be a 
collection of closely spaced CW carriers of known amplitude and phase 
across the passband of the SSB transceiver. You could then measure the 
amplitude and phase variations of each and use the in a FFT-based 
filter that simulates not only the HF channel, but the filters in the 
radios. 


Mathematically, both approaches are of course pretty much equivalent, 
it's just a difference of implementation. 


Phil 


From wtb@partyline.org Wed Mar 15 22:29:12 1995 
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id WAAOQ2747 for 
<hfsig@tapr.org>; Wed, 15 Mar 1995 22:29:09 -0600 
From: wtb@partyline.org 
Received: from partyline.org by uustar.starnet.net with UUCP id AA22454 
(5.67b/IDA-1.5 for hfsig@tapr.org); Wed, 15 Mar 1995 22:11:02 -0600 

Received: by partyline.org 

id OV4DAQ0C Wed, 15 Mar 95 22:09:11 -0600 


Message-Id: <9503152209.0V4DAQ0@partyline.org> 
Organization: Party Line Entertainment Network 
X-Mailer: TBBS/PIMP v3.29 

Date: Wed, 15 Mar 95 22:09:11 -0600 

Subject: [HFSIG:322] RE: THOUGHTS ON HF CHANNEL S 
To: hfsig@tapr.org 


Isn't it true that those of us who are planning to do our DSP on the 
DSP93, a separate box from our computers, would want the channel 
simulation (recordings) as analog tapes??? 

Bill NOLIK 
From karn@qualcomm.com Wed Mar 15 23:46:12 1995 
Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id XAAQ2924 for 
<hfsig@tapr.org>; Wed, 15 Mar 1995 23:46:09 -0600 
Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id VAA27211; 
Wed, 15 Mar 1995 21:44:22 -0800 
Date: Wed, 15 Mar 1995 21:44:22 -0800 
From: Phil Karn <karn@qualcomm. com> 
Message-Id: <199503160544.VAA27211@servo.qualcomm. com> 
To: hfsig@tapr.org 
CC: wtb@partyline.org 
In-reply-to: <9503152209.0V4DA00@partyline.org> (wtb@partyline.org) 
Subject: Re: [HFSIG:325] RE: THOUGHTS ON HF CHANNEL S 


>Isn't it true that those of us who are planning to do our DSP on the 
>DSP93, a separate box from our computers, would want the channel 
>simulation (recordings) as analog tapes??? 


Not really. Who says I have to run my simulations on my DSP-93? Since 
they don't have to run in real time, I could do them much more easily 
on a general purpose PC. 


Phil 


From FORRERJ@frl.orst.edu Thu Mar 16 11:01:34 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA0Q5739 for 
<hfsig@tapr.org>; Thu, 16 Mar 1995 11:01:30 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA25010 for <hfsig@tapr.org>; Thu, 16 Mar 1995 
01:36:19 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Thu, 16 Mar 95 8:56:05 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Thu, 16 Mar 95 8:55:44 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Thu, 16 Mar 1995 08:55:43 PST8PDT 
Subject: Re: [HFSIG:324] Re: Thoughts on HF channel simulation 
Priority: normal 


X-mailer: PMail v3.0 (Ria) 
Message-ID: <4C21EE46B0C@frl.orst.edu> 


Phil, 


>>first introduced. Separate from the simulator was a PRBS probe 
>>generator, clocked such that the main lobe would fit comfortably in the 
>>passband (~2 kHz) of an ssb transmitter. This was transmitted over 
>>various HF channels, and the baseband receiver output (with AGC off) 
>>recorded on an instrumentation tape recorder. Nowadays, of course, 

> 


I good idea I agree - this is actually what the Watterson group did, 
however, 

after characterising the channel, went ahead and built the simulation 
model. The Watterson paper is actually good reading about acquiring channel 
response. 


I have read a few papers where "the channel" is implemented as a FIR filter. 
The FIR filter, in this case, having non-symetric filter coefficients, thus 
able to produce most any amplitude/phase responses. The taps are then fed 

in real time from a stored data stream. This then gives "realism". I guess 
it would not be impossible to extract the coefficients for a given channel, 
given a procedure outline above. 


>Bingo, this is exactly what I had in mind. 

> 

>A possible alternative to the pseudo-random bit stream would be a 
>collection of closely spaced CW carriers of known amplitude and phase 
>across the passband of the SSB transceiver. You could then measure the 
>amplitude and phase variations of each and use the in a FFT-based 
>filter that simulates not only the HF channel, but the filters in the 
>radios. 

> 

>Mathematically, both approaches are of course pretty much equivalent, 
>it's just a difference of implementation. 

> 

>Phil 

> 


Johan, KC7WW 


From karn@unix.ka9q.ampr.org Fri Mar 17 12:46:41 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA14230 for 
<hfsig@tapr.org>; Fri, 17 Mar 1995 12:46:33 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id KAAQ0237; Fri, 
17 Mar 1995 10:35:18 -0800 

Date: Fri, 17 Mar 1995 10:35:18 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199503171835 .KAAQ0237@unix.ka9q.ampr.org> 

To: tcp-group@ucsd.edu, hfsig@tapr.org 


Subject: Fano decoder uploaded to ftp.ucsd.edu 
My Fano (sequential) decoder package is now available as 


ftp://£tp.ucsd.edu/hamradio/packet/tcpip/incoming/fano.tar. gz 
ftp://£tp.ucsd.edu/hamradio/packet/tcpip/incoming/fano.zip 


Three different rate 1/2 constraint length 32 convolutional codes are 
supported. The decoder operates on 8-bit soft decisions. A routine is 
provided to build the decoder metric table assuming gaussian noise at 
some estimated Es/NO. By substituting different metric tables, the 
decoder can be adapted to run on other kinds of channels such as the 
binary symmetric channel (BSC), i.e., with hard decoding. 


Using GCC 2.5.8 on a 66 Mhz 486DX2 in protected (32-bit) mode, the 
decoder runs at about 300,000 branches per second. This translates 
directly to 300,000 bits/sec on a "clean" channel. Noisy packets 
decode more slowly, as is characteristic for a sequential decoder. The 
performance curve is quite steep, as expected for a strong, long 
constraint length code. Simulation results show that at an Eb/NO of 
4dB, only about 1.6% of the packets decode at half speed or 

slower. Below about 2.5-3dB, things start to fall apart as expected. 


Although the encoder/decoder itself is in portable ANSI C, the test 
driver assumes a UNIX (specifically BSDI1.1) environment with 
curses/termcap. Also, the synthetic gaussian noise generator uses 
log() and sqrt() quite heavily. Some 386/486 math libraries don't use 
the native FPU instructions for these functions, so they can be quite 
slow. 


My Viterbi (maximum likelihood) decoder is next. 


--Phil 


From FORRERJ@frl.orst.edu Sat Mar 18 18:57:46 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id SAA21401 for 
<hfsig@tapr.org>; Sat, 18 Mar 1995 18:57:42 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id JAA07834 for <hfsig@tapr.org>; Sat, 18 Mar 1995 
09:32:03 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Sat, 18 Mar 95 16:51:55 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Sat, 18 Mar 95 16:51:39 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Sat, 18 Mar 1995 16:51:33 PST8PDT 
Subject: Re: [HFSIG:328] Fano decoder uploaded to ftp.ucsd.edu 
Priority: normal 
X-mailer: PMail v3.0 (Ria) 


Message-ID: <4FAOF1155A0@fr1l.orst.edu> 
Phil, 
Thanks - that is great news. I'll be trying that out soon. 


-Johan 

From karn@unix.ka9q.ampr.org Sat Mar 18 21:39:49 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id VAA22215 for 
<hfsig@tapr.org>; Sat, 18 Mar 1995 21:39:45 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id TAAQ1816; Sat, 
18 Mar 1995 19:35:15 -0800 

Date: Sat, 18 Mar 1995 19:35:15 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199503190335.TAAQ1816@unix.ka9q.ampr.org> 

To: hfsig@tapr.org 

In-reply-to: <4C21EE46B0C@frl.orst.edu> (FORRERJ@fr1.orst.edu) 

Subject: Re: [HFSIG:327] Re: Thoughts on HF channel simulation 


>I have read a few papers where "the channel" is implemented as a FIR filter. 
>The FIR filter, in this case, having non-symetric filter coefficients, thus 
>able to produce most any amplitude/phase responses. The taps are then fed 
>in real time from a stored data stream. This then gives "realism". I guess 
>it would not be impossible to extract the coefficients for a given channel, 
>given a procedure outline above. 


Why not? Just send impulses down a real HF channel. What comes out of 
the receiver will be, by definition, the impulse response of the 
channel. These could be used in a time-varying FIR filter to later 
simulate the same channel as many times as you wish. 


Phil 


From karn@unix.ka9q.ampr.org Sun Mar 19 01:20:37 1995 

Received: from unix.ka9q.ampr.org (unix.ka9q.ampr.org [129.46.80.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id BAA23563 for 
<hfsig@tapr.org>; Sun, 19 Mar 1995 01:20:33 -0600 

Received: (karn@localhost) by unix.ka9q.ampr.org (8.6.10/8.6.5) id XAAQ2636; Sat, 
18 Mar 1995 23:16:03 -0800 

Date: Sat, 18 Mar 1995 23:16:03 -0800 

From: Phil Karn <karn@unix.ka9q.ampr.org> 

Message-Id: <199503190716.XAA0Q2636@unix.ka9q.ampr.org> 

To: hfsig@tapr.org, tcp-group@ucsd.edu 

Subject: Viterbi decoder package released 


As promised, I have uploaded my Viterbi decoder package: 


ftp://f£tp.ucsd.edu/hamradio/packet/tcpip/incoming/viterbi.tar. gz 
ftp://f£tp.ucsd.edu/hamradio/packet/tcpip/incoming/viterbi.zip 


This package implements a coder and soft decision Viterbi (maximum 
likelihood) decoder for the rate 1/2 K=7 NASA standard convolutional 


code. It includes a driver program for test purposes. 


The decoder runs at about 45.5 kilobits/sec on a 66 MHz 486DX2 under 
BSDI1.1 and gcc 1.42. (Interestingly enough, it runs only about 40.8 
kb/s under gcc 2.5.8, even with full optimization). This is about 
6.6x slower than my Fano decoder on a "clean" channel. But unlike a 
Fano decoder, which bogs down on a noisy channel, the Viterbi decoder 
runs at a constant rate even when the signal is very weak (though not 
without errors, of course). 


Phil 

From ve6éahm@ve6ahm-1.ampr.ab.ca Sun Mar 19 17:16:12 1995 

Received: from scapa.cs.ualberta.ca (Sscapa.cs.ualberta.ca [129.128.4.44]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id RAA26762 for 

<hfsig@tapr.org>; Sun, 19 Mar 1995 17:16:08 -0600 

Received: from ve6kik by scapa.cs.ualberta.ca with UUCP id <13061-3>; Sun, 19 Mar 

1995 16:10:55 -0700 

Received: from ve6ahm-1.ampr.ab.ca by ve6kik.ampr.ab.ca with smtp 
(Smail3.1.28.1 #5) id mOrqRIK-OOOH8LC; Sun, 19 Mar 95 13:39 WET 

Received: (from ve6ahm@localhost) by ve6éahm-1.ampr.ab.ca (8.6.9/8.6.9) id BAAQQ773 

for hfsig@tapr.org; Mon, 20 Mar 1995 01:52:29 -0700 

From: Les Davies <ve6éahm@ve6ahm-1.ampr.ab.ca> 

Message-Id: <199503200852.BAA00773@ve6éahm-1.ampr.ab.ca> 

Subject: Re: [HFSIG:331] Viterbi decoder package released 

To: hfsig@tapr.org 

Date: Mon, 20 Mar 1995 01:52:02 -0700 (MST) 

In-Reply-To: <199503190716.XAA02636@unix.ka9q.ampr.org> from "Phil Karn" at Mar 

19, 95 01:28:29 am 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 88 


What can these packages be used for. Also what additional is required for 
them? 
Les 


From karn@qualcomm.com Sun Mar 19 18:29:42 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id SAA27073 for 
<hfsig@tapr.org>; Sun, 19 Mar 1995 18:29:38 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id QAA12011; 
Sun, 19 Mar 1995 16:27:10 -0800 

Date: Sun, 19 Mar 1995 16:27:10 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199503200027 .QAA12011@servo.qualcomm. com> 

To: hfsig@tapr.org 

In-reply-to: <199503200852.BAAQ0773@ve6ahm-1.ampr.ab.ca> (message from Les Davies 
on Sun, 19 Mar 1995 17:26:34 -0600) 

Subject: Re: [HFSIG:332] Re: Viterbi decoder package released 


Both packages consist just of the encoder/decoder subroutines plus 
test drivers. By themselves they are primarily intended for 
experimentation and education. But you could also integrate them into 


a system if you are so inclined. 
Phil 


From slewis@pacsat.demon.co.uk Sun Mar 26 16:08:05 1995 

Received: from post.demon.co.uk (post.demon.co.uk [158.152.1.72]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA11627 for 

<hfsig@tapr.org>; Sun, 26 Mar 1995 16:08:00 -0600 

Received: from pacsat.demon.co.uk by post.demon.co.uk id aa01997; 
26 Mar 95 22:50 GMT-60:00 

Date: Sun, 26 Mar 1995 21:48:19 GMT 

From: Simon Lewis <slewis@pacsat.demon.co.uk> 

Reply-To: slewis@pacsat.demon.co.uk 

Message-Id: <22@pacsat.demon.co.uk> 

To: hfsig@tapr.org 

Subject: ACARS SOFTWARE WANTED 

X-Mailer: FIMail V0.9d 

X-User: Alpha Test Version Of FI-Mail, DisWin 1.5C:\WINSOCK\WINDIS 

Lines: 11 


Hi All 

I'm in need of some ACARS decoding software for the aero data system. 

I know that this isnt an HF sig mode but any help from like minded data 
individuals would be appreciated. 


| 73 From: Simon Lewis GM4PLM - Helensburgh - Strathclyde - Scotland | 
| Packet: GM4PLM @ GB7SAN.##78.GBR.EU Email: slewis@pacsat.demon.co.uk | 
| AMSAT - UK Member 4282 *x*xk*k*k SUPPORT YOUR LOCAL AMSAT GROUP xxxx | 


From wtb@partyline.org Sun Mar 26 16:09:04 1995 
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id QAA11649 for 
<hfsig@tapr.org>; Sun, 26 Mar 1995 16:09:01 -0600 
From: wtb@partyline.org 
Received: from partyline.org by uustar.starnet.net with UUCP id AA27407 
(5.67b/IDA-1.5 for hfsig@tapr.org); Sun, 26 Mar 1995 16:01:42 -0600 
Received: by partyline.org 
id ONVAHOO1 Sun, 26 Mar 95 16:59:27 
Message-Id: <9503261659.ONVAHOO@partyline.org> 
Organization: Party Line Entertainment Network 
X-Mailer: TBBS/PIMP v3.30 
Date: Sun, 26 Mar 95 16:59:27 
Subject: silence 
To: hfsig@tapr.org 


No info from SIG for over a week.. Is this normal or fault?? 

Bill NOLIK 

From FORRERIJ@frl.orst.edu Mon Mar 27 11:09:44 1995 

Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA17048 for 


<HFSIG@tapr.org>; Mon, 27 Mar 1995 11:09:34 -0600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAA11130 for <HFSIG@tapr.org>; Mon, 27 Mar 1995 
01:41:44 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 
Mon, 27 Mar 95 9:02:05 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Mon, 27 Mar 95 9:01:52 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: HFSIG@tapr.org 


Date: Mon, 27 Mar 1995 09:01:46 PST8PDT 
Subject: HFSIG activities 

Priority: normal 

X-mailer: PMail v3.0 (Ria) 


Message-ID: <5CA409544FC@frl.orst.edu> 
Hi All, 


After my plea for help, I have not heard from anyone, so without anyone 
to help out, this is what probably will be happening for a while: 


1) Don't dispair - I have not lost interest. As soon as things settle down 

with my present time sink, there will be more time to spend on helping with 
the dissemination of ideas. With the way things are looking right now, this 
may be around September. 


2) I am working with some on a few worthy projects - one of these are MFSK. 
It appears that this technology is far from dead and have taken a very 
interesting direction, for example: Viterbi decoding for both error- 
control and synchronisation. More on this at a later opportunity. 

The other is that I received a DSP-93 and will be porting a number of 
applications that I have running on the TI DSK to this platform. 

Initially, this will be the W9GR denoiser and the HF DSP modems for 
AMTOR/PACTOR. 


Activity on HFSIG will be what you make of it, I'm sure there are lots 
of interesting ideas out there - use the opportunity. 


73's 


Johan, KC7WW 


From fperkins@onramp.net Mon Mar 27 19:01:59 1995 

Received: from ns.onramp.net (ns.onramp.net [199.1.11.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id TAA19759 for 
<hfsig@tapr.org>; Mon, 27 Mar 1995 19:01:57 -0600 

Received: from 199.1.11.156 (dal56.onramp.net [199.1.11.156]) by ns.onramp.net 
(8.6.5/8.6.5) with SMTP id SAA23494 for <hfsig@tapr.org>; Mon, 27 Mar 1995 
18:55:29 -0600 

Date: Mon, 27 Mar 1995 18:55:29 -0600 

Message-Id: <199503280055.SAA23494@ns.onramp.net> 


From: fperkins@onramp.net 

Subject: Re: [HFSIG:336] HFSIG activities 
To: hfsig@tapr.org 

X-Mailer: AIR Mail 3.X (SPRY, Inc.) 


Hi Johan, 
Great to hear you have joined the DSP-93 development team! 
73 Frank WB5IPM 


From wtb@partyline.org Tue Mar 28 11:10:52 1995 
Received: from uustar.starnet.net (uustar.starnet.net [128.252.135.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA23559 for 
<hfsig@tapr.org>; Tue, 28 Mar 1995 11:10:49 -0600 
From: wtb@partyline.org 
Received: from partyline.org by uustar.starnet.net with UUCP id AA23150 
(5.67b/IDA-1.5 for hfsig@tapr.org); Tue, 28 Mar 1995 10:52:49 -0600 
Received: by partyline.org 
id OGLIHO05 Tue, 28 Mar 95 11:48:53 
Message-Id: <9503281148 .OGLIHOO@partyline.org> 
Organization: Party Line Entertainment Network 
X-Mailer: TBBS/PIMP v3.30 
Date: Tue, 28 Mar 95 11:48:53 
Subject: [HFSIG:336] HFSIG ACTIVITIES 
To: hfsig@tapr.org 


Johan 

Dont feel pressed, its only a hobby. I was merely checking, not pushing. 

You guys have finally pushed me into 486/50 with windows so I have weeks 

of studying to do. I'm also trying to get my hands on Phil's viterbi.zip 

thru ftpmail and so far have failed miserably. Good luck on your pursuits. 
BILL NOLIK 

From gjones@tenet.edu Tue Mar 28 12:12:07 1995 

Received: from Alice-Thurman.tenet.edu (Alice-Thurman.tenet.edu [198.213.2.5]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id MAA23920 for 

<hfsig@tapr.org>; Tue, 28 Mar 1995 12:12:05 -0600 

Received: (from gjones@localhost) by Alice-Thurman.tenet.edu (8.6.9/8.6.9) id 

MAA25465 for hfsig@tapr.org; Tue, 28 Mar 1995 12:05:29 -0600 

From: Greg Jones <gjones@tenet.edu> 

Message-Id: <199503281805 .MAA25465@Alice-Thurman.tenet.edu> 

Subject: Johan's Schedule 

To: hfsig@tapr.org (HF SIG mailing) 

Date: Tue, 28 Mar 1995 12:05:28 -0600 (CST) 

X-Mailer: ELM [version 2.4 PL23] 

Content-Type: text 

Content-Length: 1639 


Greeting HF SIG. Johan approached me before the TAPR annual meeting 
regarding the fact that he would be very busy preparing for his dissertation 
defense over the next 6 months. I can literally understand his position, as 
I am taking my candidacy exams next week. 


Problem: 


1. HF SIG will come to a complete halt over the next 6 months unless we find 
someone to step froward and at least provide the necessary facilitation to 
continue discussion. 


2. Johan will return and be available to help, but just not to do all the 
talking during the period. 


3. The group needs a scribe for the activity....Johan has been doing this as 
well..and I can understand why he might feel a little over worked :-) 


So - who has just a little time in the next 6 months to help organize and 
report activity within the group....not to completely step into Johan's 
shoes...just to help keep the topic of discussion focused until Johan can 
return in full force and we can call him 'Dr. Forrer’. 


We really need to find someone who will step forward and volunteer for 
either some or all of this, or the HF SIG will be in a reduction mode. I 
would hate to see that, based on the tremendious dialog and work that has 
been accomplished thus far. 


If you think you can help - contact either Johan or myself. 


Cheers - Greg 


TAPR Office (817) 383-0000 | Internet: gjones@tenet.edu 

From JALOCHA@chopin.ifj.edu.pl Wed Mar 29 05:05:07 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id FAA28499 for 
<hfsig@tapr.org>; Wed, 29 Mar 1995 05:05:00 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id MAA@6372 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Wed, 29 Mar 1995 12:55:30 +0200 

Date: Wed, 29 Mar 1995 11:55 GMT+1 

Subject: Re: [HFSIG:336] HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <547C7D2B20A02883@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Let me say about what I am doing: 
I am still at the stage of coding the parallel carrier modem into the 


DSPCARD4. The current code can send out the tones, with a reasonable 
initial phase set (so the Crest factor isn't too bad). The receiver's 


FFT works too. There are some provisions for shifting the receiver's 
sampling point for symbol synchronization. 


Missing items: 


1. Inter-symbol interference: how to send and receive symbols 
so they don't leak one into another across time and frequency. 
Yesterday I have worked out the problem (at last !) and I feel 
beeing myself on a straight way. 

2. Bit endcoding/decoding. 

3. Symbol synchronization. 

4. Tuning indication. 


I believe I have good ideas to follow in every of these aspects 
so the whole project is only a matter of time... 


By the way a little thing which came across my mind recently: 
You remember that idea of putting same information at every carrier 
and then doing a majority vote at the receiver. 


If a,b,c,... are the bits to be sent the coding pattern looks like this: 


1 . <- Window number 
a 
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The intended feature of this scheme is time and frequency diversity. 

But this scheme has another interresting feature: being mistuned 

by one carrier makes little harm (your symbol timing shifts and 

you loose 2 data streams out of 15 but the message is still decodeable). 

I am not sure what happens if you get mistuned by a fraction of the carrier 
Spacing... 


Are there schemes which provide resistance again any (but not to large) 
mistune so you don't care much about tuning your receiver to these 
last Hertz's ? 


I could think of one such scheme: our elementary symbol would be 

a constant rate sweep across the whole available band say 300..3000 Hz. 

At the receiver you listen to the sweep through several narrow filters 

(this is done with the help of FFT). Every filter gives you the same 

data stream but shifted in time. Now you have time and frequency diversity 
and reasonable insensitivity to mistuning your receiver (or possible Doppler 
shift if it doesn't change too fast with time). 


Pawel 

From paulr@hagar.udc.neweast.ca Wed Mar 29 07:14:55 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id HAA29182 for 

<hfsig@tapr.org>; Wed, 29 Mar 1995 07:14:46 -0600 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA27971; Wed, 29 Mar 95 13:08:00 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA796498681; Wed, 29 Mar 95 09:37:41 nst 

Date: Wed, 29 Mar 95 09:37:41 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 65 Text 

Message-Id: <9502297964.AA796498681@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:340] Re: HFSIG activities 


Pawel, 


One thing I have come across that may help with being off frequency when using 
an FFT is: zero padding. 


That is you use an FFT several times larger than necessary, and fill the extra 
points with zeros. 


| X | XXX 

| x | XXXXXXX 

| x | XXXXXXXXXXX 

nee ; Oe [phe snes tae reese XXXXXXXXXXXXXXX_ 
F E 

Original 64pt FFT Zero Padded 512pt FFT Output 


The tones that were single "bars" in the original FFT, will now become "bumps" 
over the several new bars/bins around the frequency. If the tone was not on 
frequency in the original FFT, then one of the bins to one side of this 
frequency will have more energy in the new FFT. i.e. 8000HzZ Sampling, 64point 
FFT = 125Hz/point. If zero pad the FFT to 512point = 15.625Hz/point which should 
be sufficient resolution for radio frequency error? And all you do is add up the 
power of the 8 groups of every (512/64=8) 8th point, and choose the point set 
that has the highest power as where the tones are centred. 


Care must be taken in that there may be some distortion to the phases of the 
points, although my initial simulations showed this to be negligible. 


There have also been suggestions to me, that since our tones are orthogonal, 
that instead of zero padding, you repeat the FFT input data to fill the larger 


FFT input buffer. I understand that in some tests this has worked well. But in 
my own simulations I have seen occasional strange results (human error?). I am 
also worried about what may happen if the radio is off frequency, causing the 

received tones to no longer be completely orthogonal, and the resulting phase 

descrepancies at the repeat boundaries to causes erroneous FFT output. 


As well as comments on above by anyone, I am extremely interested in your 
methods for solving: 


1. Inter-symbol interference 
I am looking at shaping the signals using either sin() or sin()‘%2, 
this reduced harmonics at the phase/freqency changes between symbols 
as the signal power drops to zero. But the shaping causes a large amount 
of energy in the adjacent FFT Bin. (Presently using sin() as higher 
centre to lobe ratio, and the further lobes are in the dirt anyway). 
Problem is shaping reduces the overall bit energy, reducing the SNR. 


2. Bit endcoding/decoding. 
Are you planning an interleaved Golay code, or similiar? I've seen alot 
of coding software posted here. 


I am uncertain if I correctly understand your diagram, showing the 
staggered bit output on easy tone successively. If this is done, then 
each bit is sent 16 times, won't some form of error correction coding be 
more efficient? 


3. Symbol synchronization. 
If you shape the signal as in 1 above, then tracking the average audio 
power gives you a clock. 


4. Tuning indication. 
If you use the Zero Padded FFT, then the Choice of point set gives a 
course tuning indication. A larger FFT would bring it in closer. 


Paul Russell 


From FORRERJ@frl.orst.edu Wed Mar 29 11:22:57 1995 
Received: from amanda.bus.orst.edu (amanda.BUS.ORST.EDU [128.193.10.36]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id LAA30652 for 
<hfsig@tapr.org>; Wed, 29 Mar 1995 11:22:44 -Q600 
Received: from frl.orst.edu (FRL.ORST.EDU [128.193.226.10]) by amanda.bus.orst.edu 
(8.6.9/8.6.9) with SMTP id BAAO3916 for <hfsig@tapr.org>; Wed, 29 Mar 1995 
01:15:52 -0800 
Received: from FRL/MERCURY_MAILER by frl.orst.edu (Mercury 1.11); 

Wed, 29 Mar 95 9:14:56 PST8PDT 
Received: from MERCURY_MAILER by FRL (Mercury 1.11); Wed, 29 Mar 95 9:14:29 
PST8PDT 
From: "Johan Forrer" <FORRERJ@frl.orst.edu> 
Organization: Forest Research Lab. Oregon State 
To: hfsig@tapr.org 
Date: Wed, 29 Mar 1995 09:14:22 PST8PDT 
Subject: HFSIG activities 


Priority: normal 
X-mailer: PMail v3.0 (R1a) 
Message-ID: <5FA77D134D7@frl.orst.edu> 


Hi All, 
On a more positive angle - a short update: 


Pawel - congratulations on your progress with the parallel modem. One 
interesting article that I have recently worked through, concerning symbol 
synchronisation for MFSK, uses the Viterbi algorithm. This, in essence 

is how they do it: 


You need to compute a sliding FFT, at least over several instances per 
symbol, then feed the output of the FFT bins at each instance into 

a decoder trellis. Do this over several symbols. The output of the decoder 
now will tell you the best path, in maximum likelihood sense, through 

the trellis, i.e. at which instance you have the center of the symbol. 

The same trellis is then also used for data error-control. For a 
description of the paper: 


"Improved HF modem using convolutional coding." by B. Honary, F. Zolghadr, 
M. Darnell, and M.Maundrell. In Electronics & Communications Engineering 
Volume 4(2) April 1992. (Thanks to Frode for the reference). 


I also have been following Adrian's (G4ZHZ) work on MFSK. This is really 
outstanding - Adrian is busy dealing with some challenging issues. 

I'll let Adrian give us a overview of this when he is ready - better will 
encourage him to write an article about it! Just to fill you in a bit: One 
of these is how to deal with the distortion inherent in a numerical 
approach, i.e., local oscillator distortion, but also with dynamic range 
of 16-bit DSP for FFT's vs. a correlator (matched filter) approach. These 
things are easy to talk about but another matter to live with in your actual 
implementations. This is where one have to carefully weigh your choice in 
DSP chips - do you use the appropiate architecture, should you rather use 
a floating point device? Another idea is to use a marriage between analog 
and DSP techniques. On this matter, if anyone has some ideas on a good 
analog front-end processor that can produce high resolution I/Q outputs, I 
am very interested. 


We are still looking for help with this SIG: As you can gather from the 
recent contributions, please consider helping out for the next few months. 


Thanks, 


Johan, KC7WW 
From paulr@hagar.udc.neweast.ca Wed Mar 29 11:50:55 1995 
Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id LAA30781 for 
<hfsig@tapr.org>; Wed, 29 Mar 1995 11:50:48 -0600 
Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AA29040; Wed, 29 Mar 95 17:43:59 GMT 
Received: from cc:Mail by ccsmtp.udc.neweast.ca 


id AA796515241; Wed, 29 Mar 95 14:13:13 nst 
Date: Wed, 29 Mar 95 14:13:13 nst 
From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 
Encoding: 18 Text 
Message-Id: <9502297965 .AA796515241@ccsmtp.udc.neweast.ca> 
To: hfsig@tapr.org 
Subject: DSP Floating Point Unit 


FYI 

I am uncertain if I mentioned It before, but the best deal I've seen 
on a Floating Point standalone DSP unit is the DSP Tools unit. 

It connects to a PC via a parallel port, or runs standalone. 

Has a 33MHz TMS320C31 (50MHz available), and FLASH ROM for code 
storage. Audio is via a TLC32040 AIC. 


$299.00 US (email Dave Jervis at DSP Tools for info: 
davejervis@aol.com) 


The floating point is easier than integer in that you don't have to 
worry about dynamic range of the signal (clipping etc.) during the 
stages of signal processing. But it costs more. 


Query: How mush is the DSP-93 and what processor does it use? 
Paul Russell 


From karn@qualcomm.com Wed Mar 29 14:30:35 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id 0AA31883 for 
<hfsig@tapr.org>; Wed, 29 Mar 1995 14:30:32 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id MAA23656; 
Wed, 29 Mar 1995 12:26:30 -0800 

Date: Wed, 29 Mar 1995 12:26:30 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199503292026.MAA23656@servo.qualcomm. com> 

To: paulr@hagar.udc.neweast.ca 

CC: hfsig@tapr.org 

In-reply-to: <9502297964.AA796498681@ccsmtp.udc.neweast.ca> 
(paulr@hagar.udc.neweast.ca) 

Subject: Re: [HFSIG:341] Re: HFSIG activities 


Paul, 


Your zero-padded FFT idea is basically a rectangular sampling window that's 
shrunk to take up less than the whole time. Have you considered any of the 
other sampling windows? There are many to consider: Hamming, hanning, 
Kaiser, etc. 


The right choice of sampling window is important in rejecting strong 
in-band interference in a m-ary orthogonal FSK scheme. Otherwise, the 
windowing artifacts would cause energy to spread over much of the spectrum 
after the FFT. 


Phil 

From karn@qualcomm.com Wed Mar 29 14:36:08 1995 

Received: from servo.qualcomm.com (servo.qualcomm.com [129.46.128.14]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id 0AA31973 for 
<hfsig@tapr.org>; Wed, 29 Mar 1995 14:36:01 -0600 

Received: (karn@localhost) by servo.qualcomm.com (8.6.10/QC-BSD-2.5) id MAA23662; 
Wed, 29 Mar 1995 12:32:00 -0800 

Date: Wed, 29 Mar 1995 12:32:00 -0800 

From: Phil Karn <karn@qualcomm. com> 

Message-Id: <199503292032 .MAA23662@servo.qualcomm.com> 

To: hfsig@tapr.org 

In-reply-to: <5FA77D134D7@frl.orst.edu> (FORRERJ@fr1l.orst.edu) 

Subject: Re: [HFSIG:342] HFSIG activities 


Johan, 


It's amazing how many uses people have found for the Viterbi algorithm 
beyond straight FEC. Several textbooks discuss using it to do maximum 
likelihood decoding of signals with intersymbol interference. In the 

case of duobinary, a 3-level signalling scheme with deliberate, 

controlled intersymbol interference, a Viterbi decoder buys back xallx 

of the S/N loss that would otherwise result from going from 2 levels to 3. 


Of course, the range of channels is somewhat limited by the Viterbi 
decoder's exponential complexity function. 


Phil 


From JALOCHA@chopin.ifj.edu.pl Thu Mar 30 07:24:10 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id HAAQ4719 for 
<hfsig@tapr.org>; Thu, 30 Mar 1995 07:24:02 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id PAA17589 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Thu, 30 Mar 1995 15:14:12 +0200 

Date: Thu, 30 Mar 1995 15:15 GMT+1 

Subject: Re: [HFSIG:341] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <3992D3FF80A03CC2@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Hello Paul, 


>As well as comments on above by anyone, I am extremely interested in your 
>methods for solving: 


> 
>1. Inter-symbol interference 
> I am looking at shaping the signals using either sin() or sin()‘%2, 


After scratching my head a lot I decided to use sin()%2... 


The numbers I work with right now are: 


Sampling: 9600 Hz 

FFT size: 128 points -> 64 frequency bins between © and 4800 Hz 

I take even bins for data transmition, odd ones are for tuning. 

I use 15 carriers, the first one is #8 (600 Hz), the last one is 2700 Hz. 
This fits into 300-3000 Hz band. 


Window: sin(x)*%2 for x=0..PI, the total length of the window 
is 128 samples (same as the FFT size). I use same window for transmit 
and receive. 


Spacing between symbols is 64 samples on I-part of the carrier 

and same for the Q-part. 

On both I- and Q-parts I use a BPSK coding: a 180 degrees change 

in phase is a "0", no change is a "1". I- and Q- symbols are shifted 

by 32 samples. This is the maximum bit packing you can do theoretically. 


I'm going to try as well a carrier-on/carrier-off approach. 


With sin()*2 window I expect inter-symbol crosstalks of about 1/6 
to a symbol adjacent in time or in frequency, -1/12 to symbols 
"across diagonals". For a symbol on the carrier #12 the crosstalk 
pattern looks like this: 


mes [oor Joos [ees > Eines «| S-de | = 64 samples 


carrier #14: -1/12 1/6 -1/12 
carrier #12: 1/6 4; 1/6 


carrier #10: -1/12 1/6 -1/12 


For a worst case the total crosstalk from adjacent symbols 
reaches 1 so it may overcome the symbol you are interested in. 
I correct for crosstalk by subtracting adjacent symbols 
according to the above pattern. 


VVVNV Vv 


this reduced harmonics at the phase/freqency changes between symbols 
as the signal power drops to zero. But the shaping causes a large amount 
of energy in the adjacent FFT Bin. (Presently using sin() as higher 
centre to lobe ratio, and the further lobes are in the dirt anyway). 
Problem is shaping reduces the overall bit energy, reducing the SNR. 


This is a very tricky thing: I would say that using rectangular window 

(no shaping) makes your symbol's energy go to other frequency bins 

(sounds the other way you say ?). Shaping makes the bit energy to concentrate 
in the bin you want. 

With rectangular window you don't see this energy being spread around 

only because your other frequency bins are spaced just right. 

If they were a bit off, you would notice... 


>2. Bit endcoding/decoding. 


This point was the way I encode the bits into the carrier states (look above). 


> Are you planning an interleaved Golay code, or similiar? I've seen alot 
> of coding software posted here. 
I forsee the following "simple" schemes: 


no FEC at all (just to see how the modem alone works 

11 data + 4 CRC bits FEC code capable of correcting single error 

15 bit Walsh functions (how many error can these correct ?) 

"send same bit 15 times" with majority coding at the receiver 

(cruel but can correct up to 7 errors). 

4. with 24 carriers I might use a 12 data bits + 12 CRC bits Golay code 
which can correct up to 3 errors. 


WNR © 


1,2,3 and 4 would additionally involve spreading the bits in time 
to gain certain resistance against error bursts. 

For details about 1 and 3 look my previous posts... or I send them 
to you if you haven't got them. 


For easy start I will use use AX.25 framing and protocol: I take a HDLC 
frame and put the bits one by one (including the stuffing bits 
and the frame markers) onto the carriers. 


I am uncertain if I correctly understand your diagram, showing the 
staggered bit output on easy tone successively. If this is done, then 
each bit is sent 16 times, won't some form of error correction coding be 
more efficient? 


VV VV 


This is right: every bit gets send 15 times but I am not saying this is an 
efficiant FEC - this was only an example, just to present the idea of 
a signal which is little sensitive to a mis-tune at the receiver. 


>3. Symbol synchronization. 


> If you shape the signal as in 1 above, then tracking the average audio 
> power gives you a clock. 

Not so obvious I'm afraid... if you pack symbols as dense in time as I am 
trying to. 


>4. Tuning indication. 
> If you use the Zero Padded FFT, then the Choice of point set gives a 
> course tuning indication. A larger FFT would bring it in closer. 


Again not obvious when packing so dense in frequency as I am trying to do 
but I hope I would get the mis-tune indication by using the odd carrier 
information. Note, that for the moment I do not try to correct the mis-tune 
- I only want to indicate it so the operator corrects the receiver. 


Progress (rather regress) report: 


I have made up cross-talk correcting code yesterday - seems to work fine. 


Then I have put in the bit encode/decode (two BPSK's on I and Q 

shifted by half the symbol length). The result: constant bit patterns 

are passed well, but when I apply varying bit patterns I get some 

bits flipped... 

Might be a symbol timing problem - the timing is fixed now - but 
adjusting the timing by hand didn't make much difference :-( 

I hope it's a software bug somewhere and not a failure of a whole concept. 


Pawel 

From paulr@hagar.udc.neweast.ca Thu Mar 30 13:31:59 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAAQ6962 for 

<hfsig@tapr.org>; Thu, 30 Mar 1995 13:31:49 -0600 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AAQ2375; Thu, 30 Mar 95 19:24:43 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA796607685; Thu, 30 Mar 95 15:52:42 nst 

Date: Thu, 30 Mar 95 15:52:42 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 60 Text 

Message-Id: <9502307966.AA796607685@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:344] Re: HFSIG activities 


>>Your zero-padded FFT idea is basically a rectangular sampling window 
that's shrunk to take up less than the whole time. Have you considered any 
of the other sampling windows? There are many to consider: Hamming, 
hanning, Kaiser, etc. 


The right choice of sampling window is important in rejecting strong 
in-band interference in a m-ary orthogonal FSK scheme. Otherwise, the 
windowing artifacts would cause energy to spread over much of the spectrum 
after the FFT. 


Phil<< 


I shape the Initial FFT Buffer before zero padding. I use either 1/2 a sine 
cycle ( sin() ), or a raised cosine ( sin()*2 ). I also preshape the transmit 
symbols with either sin or sin‘42. The resultant receive symbols are thus shaped 
by either sin’2 or sin*4, as well as the noise being windowed. The Energy spread 
into adjacent FFT Bins is a problem. 


I like the Preshaping of the Tx symbols at the symbol rate as it provides a 
clock to the receiver, and reduces Tx spikes/harmonics at the 
phase_changes/symbol_boundaries in DPSK. Although it also reduces your average 
Tx Energy per bit. 


I'm doing simulations to analyse the Sliding FFT Window that Pawel is using, 
where the FFT input buffer is longer than the symbol. 


I think a Preshaping with a sin() at the symbol rate (64pt), and a sin()%*2 
Windowing in the receiver that is twice the width of the symbol (128pt) is 
giving me my best results: 


For DPSK, Each symbol 180degree shifted from previous: 64samples/symbol 
Receiver 128Pt FFT centred on Rx symbol. 
Best Combinations from simulations so Far: 


Tx Rx 128pt FFT Lobe Magnitudes 
Shaping Windowing (Only every 2nd point used) 
Centre: lobe 2 : lobe 4 : lobe 6 
None Sin()%2 128pt ‘4. mL/s : 1/15 : 1/36 (Pawel's?) 
Sin() 64pt None 1 : 1/3 : 1/15 : 1/36 
Sin() 64pt Sin() 64pt 1 : 1/2 : 0 : 0 
Sin() 64pt Sin()42 128Pt 1 1/2 0 : 0 


A 64 point FFT would also work, although the larger gives more frequency 
resolution. Test with a 512 point zero padded FFT gave the same ratios (at the 
corresponding bins) with more frequency resolution. 


In simulations I have seen the windowing "artifacts" spread quite well across 
the band if the wrong window is chosen, or misalligned <grin>. 


The purpose of the zero-padding is to give more frequency resolution by using a 
larger FFT, without increasing the symbol period. You do not get something for 
nothing as the "spikes" in the FFT spread out and it requires more memory and 
processing time, but it can help resolve where your carrier tones are (highest 
peaks) and thus indicate how far off frequency your radio may be. 


Paul 


From paulr@hagar.udc.neweast.ca Thu Mar 30 13:40:55 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id NAAQ7009 for 

<hfsig@tapr.org>; Thu, 30 Mar 1995 13:40:48 -0600 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AAQ2498; Thu, 30 Mar 95 19:33:47 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA796608226; Thu, 30 Mar 95 16:01:34 nst 

Date: Thu, 30 Mar 95 16:01:34 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 23 Text 

Message-Id: <9502307966.AA796608226@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Re: [HFSIG:346] Re: HFSIG activities 


Pawel, 


I have printed out all the messages I have received from hfsig re your 
design. I definitely need to re-read all of it slowly. 


I'm having trouble understanding the advantage of the sliding window FFT, 


hopefully I'll find the light <g>. 


One note: You mention you are planning on using tones from 600-2700Hz. I 
realize HF voice audio bands are supposed to be 300-3000Hz, but I have 
never seen a radio provide this. I would recommend dropping your upper 
tone, or shifting the whole down by 75Hz (525-2625). I have come across 
several commercial grade radios that only receive from ~375-2675Hz. I have 
even hit an older Harris RF230 that only passed 400-2500Hz. If the design 
is ment to operate on a wide range of radios, you may need to narrow your 
bandwidth requirements. Either lowering the sampling rate (8000Hz?) or 
using less tones may suffice. The equipment you are using may not have this 
limitation, this is just a warning. 


Now off to study the printouts... 


Paul 


From JALOCHA@chopin.ifj.edu.pl Fri Mar 31 10:05:38 1995 

Received: from nms.cyf-kr.edu.pl (nms.cyf-kr.edu.pl [149.156.1.3]) by 
dingus.n5lyt.datarace.com (8.6.10/8.6.9) with ESMTP id KAA12275 for 
<hfsig@tapr.org>; Fri, 31 Mar 1995 10:05:27 -0600 

From: JALOCHA@chopin.ifj.edu.pl 

Received: from CHOPIN.IFJ.EDU.PL (chopin.ifj.edu.pl [192.86.14.9]) by nms.cy£- 
kr.edu.pl (8.6.11/8.6.11) with SMTP id RAA27830 for <@NMS.CYF- 
KR.EDU.PL:hfsig@tapr.org>; Fri, 31 Mar 1995 17:55:11 +0200 

Date: Fri, 31 Mar 1995 17:57 GMT+1 

Subject: Re: [HFSIG:347] Re: HFSIG activities 

To: hfsig <@NMS.CYF-KR.EDU.PL:hfsig@tapr.org> 

Message-id: <195B304F80A0639F@chopin.ifj.edu.pl> 

X-Envelope-to: @NMS.CYF-KR.EDU.PL:hfsig@tapr.org 

X-VMS-To: IN%"<@NMS.CYF-KR.EDU.PL:hfsig@tapr.org>" 


Hello Paul (and others), 


> Tx Rx 128pt FFT Lobe Magnitudes 

> Shaping Windowing (Only every 2nd point used) 

> Centre: lobe 2 : lobe 4 : lobe 6 

> None Sin()%2 128pt 1 : 1/3 : 1/15 : 1/36 (Pawel's?) 
> Sin() 64pt None 1 : 1/3 : 1/15 : 1/36 

> Sin() 64pt Sin() 64pt ‘i : 1/2 : 0 : 0 

> Sin() 64pt Sin()42 128Pt 4 : 1/2 0 : 0 


I preshape both at the Tx and at the Rx with 128 pt sin()%2. 


>In simulations I have seen the windowing "artifacts" spread quite well across 
>the band if the wrong window is chosen, or misalligned <grin>. 


A bit different view at the Fourier Transform: 


While doing the transform you effectively make several 
time-domain convolutions with these functions: 


sin(k*2xpix£«t)*xwindow(t) and cos(kx2«pixf«t) «window(t) . 
t is time, £ is the base frequency of your FFT (sampling-rate/FFT-length) . 


You can regard the FFT output as a set of outputs from a series of FIR filters 
having the above shapes. 


Now, if you want to separate your frequencies as much as possible, 
those FIR filters must be sharp. Not narrow, but sharp 

- that is the "walls" must be sharp and the out of band attenuation 
must be strong. 


If you want a sharp FIR filter you must make it long. 

For low inter-carrier crosstalk the FFT length should be several 
times larger than the symbol time. 

For example try the FFT length of 256 with this window: 


sin(pi/64 * t) t = -127.5 .. 127.5 (256 values to form a 256 point window) 


You get 128 frequencies but you use every forth one to transmit 
symbols spaced at 64 points. Use the above window for both 

the receiver and the transmitter. 

You notice very low inter-carrier crosstalk at the price of having 
overshoot-type crosstalk inbetween succesive symbols on same carrier. 


I am now stuck with my ideas for phase-differential coding... 

getting the bits out while attempting to cancels the inter-symbol 
crosstalks and getting the symbol timing is too much. 

For the moment I am going to switch to carrier-on/carrier-off aproach :-) 
and test few other ideas. 


Pawel 

From paulr@hagar.udc.neweast.ca Fri Mar 31 12:57:29 1995 

Received: from hagar.udc.neweast.ca (hagar.udc.neweast.ca [198.165.24.2]) by 

dingus.n5lyt.datarace.com (8.6.10/8.6.9) with SMTP id MAA13916 for 

<hfsig@tapr.org>; Fri, 31 Mar 1995 12:57:24 -0600 

Received: from ccsmtp.udc.neweast.ca by hagar.udc.neweast.ca (5.65/1.35) 
id AAQ5815; Fri, 31 Mar 95 18:50:13 GMT 

Received: from cc:Mail by ccsmtp.udc.neweast.ca 
id AA796692015; Fri, 31 Mar 95 15:18:55 nst 

Date: Fri, 31 Mar 95 15:18:55 nst 

From: "Paul Russell" <paulr@hagar.udc.neweast.ca> 

Encoding: 33 Text 

Message-Id: <9502317966.AA796692015@ccsmtp.udc.neweast.ca> 

To: hfsig@tapr.org 

Subject: Overlapped Symbol windowing (Was HFSIG Activities) 


Pawel, 

I'm Still having trouble understanding the advantages of the 
overlapped windowing on Tx and Rx instead of just windowing at the symbol 
rate. When there is a run of same phase symbols, the tone becomes 
continuous at the Tx, whereas when the phase is shifting the tone is 


"modulated" by the windowing. This leads to more energy/bit in steams of 
same phase symbols then in streams of alternating phase bits. Also it uses 
much more processing power and memory. 


I have done up simulations, and anyone can have the file/printout. Just email 
the request and I'll email/fax back the results (simulation plots). The file 
shows the effects of phase modulating with 128pt sin()*%2 shaping on 64pt 
overlapped bits for a single channel/tone. 

Word Document 160K 

Postscript File 500K 

Or I'll Fax It 


The result of adding 128pt sin()*2 shaped symbols, overlapped at 64 pts, of 

alternating phases (+/-90degrees = 180degree shifted) is the same as a 64pt 

sin() shaped signal. (Unless there is no phase shift which gives continuous 

tone). This is what my simulations produced. Is this correct, or Do I have a 
flaw in my data? 


Also, By shaping the symbols so that they are timewise independent, we may be 
able to use multiple phases when the channel is better, thus doubling 
(4phases=2bits) or tripling (8phases=3bits) or data rate? Although the protocol 
would have to detect and adjust for this? 


Paul Russell 
paulr@neweast.ca 


If I don't figure this out soon, you are all either going to shoot me or start 
ignoring me :-) 


